Menu
▾
▴
sword-app-tech — Mailing list for discussion of SWORD implemenation and development.
You can subscribe to this list here.
| 2008 |
Jan
(22) |
Feb
(8) |
Mar
(9) |
Apr
(4) |
May
(17) |
Jun
(29) |
Jul
(11) |
Aug
(13) |
Sep
(17) |
Oct
(14) |
Nov
(41) |
Dec
(8) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(17) |
Feb
(26) |
Mar
(18) |
Apr
(1) |
May
(11) |
Jun
(20) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
|
| 2010 |
Jan
(23) |
Feb
(7) |
Mar
(9) |
Apr
(13) |
May
(5) |
Jun
|
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2011 |
Jan
(3) |
Feb
|
Mar
(2) |
Apr
(1) |
May
|
Jun
(14) |
Jul
(22) |
Aug
(1) |
Sep
(2) |
Oct
(11) |
Nov
(11) |
Dec
(35) |
| 2012 |
Jan
(17) |
Feb
(12) |
Mar
(41) |
Apr
(40) |
May
(41) |
Jun
(27) |
Jul
(9) |
Aug
(1) |
Sep
|
Oct
(6) |
Nov
|
Dec
(11) |
| 2013 |
Jan
|
Feb
(4) |
Mar
(2) |
Apr
(8) |
May
(1) |
Jun
(18) |
Jul
(10) |
Aug
(16) |
Sep
(2) |
Oct
(1) |
Nov
(14) |
Dec
(11) |
| 2014 |
Jan
(7) |
Feb
(2) |
Mar
|
Apr
|
May
(8) |
Jun
(1) |
Jul
(7) |
Aug
(10) |
Sep
(8) |
Oct
(8) |
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(4) |
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Julie A. <ja...@yo...> - 2008-11-11 18:20:16
|
Thanks! ... any feedback welcome. We could have a manually-created page listing service documents, I'd be happy to keep adding those for the time being, or are there better ways to do that? Julie Ed Summers wrote: > Wow, thanks for making the site available so quickly! Looks great. I > don't know if it's practical, but it might eventually be nice to have > a page that lists real live service documents--sorta like a > lightweight sword registry. > > //Ed > > On Mon, Nov 10, 2008 at 10:22 AM, Julie Allinson <ja...@yo...> wrote: > >> Hi all, >> >> The SWORD specifications have been assigned persistent URIs: >> SWORD profile 1.3: http://purl.oclc.org/net/sword >> <http://purl.oclc.org/NET/sword> >> SWORD types 1.0: http://purl.oclc.org/net/sword-types >> <http://purl.oclc.org/NET/sword-types> >> >> The new home page for the SWORD activity is: >> http://www.swordapp.org/ >> >> Some content relating to the original JISC-funded project will remain on >> our wiki, but information about the SWORD specifications and related >> documentation, is migrating to the SWORD web site. >> >> Best, >> >> Julie >> >> -- >> Julie Allinson <ja...@yo...> >> Digital Library Manager >> University Library & Archives, J.B. Morrell Library >> University of York, Heslington, York, YO10 5DD, UK >> tel: ++44 (0) 1904 434083 skype: j.allinson >> web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm >> -- >> >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech >> >> > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- Julie Allinson <ja...@yo...> Digital Library Manager University Library & Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 434083 skype: j.allinson web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm -- |
|
From: Ed S. <eh...@po...> - 2008-11-11 18:02:28
|
Wow, thanks for making the site available so quickly! Looks great. I don't know if it's practical, but it might eventually be nice to have a page that lists real live service documents--sorta like a lightweight sword registry. //Ed On Mon, Nov 10, 2008 at 10:22 AM, Julie Allinson <ja...@yo...> wrote: > Hi all, > > The SWORD specifications have been assigned persistent URIs: > SWORD profile 1.3: http://purl.oclc.org/net/sword > <http://purl.oclc.org/NET/sword> > SWORD types 1.0: http://purl.oclc.org/net/sword-types > <http://purl.oclc.org/NET/sword-types> > > The new home page for the SWORD activity is: > http://www.swordapp.org/ > > Some content relating to the original JISC-funded project will remain on > our wiki, but information about the SWORD specifications and related > documentation, is migrating to the SWORD web site. > > Best, > > Julie > > -- > Julie Allinson <ja...@yo...> > Digital Library Manager > University Library & Archives, J.B. Morrell Library > University of York, Heslington, York, YO10 5DD, UK > tel: ++44 (0) 1904 434083 skype: j.allinson > web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm > -- > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > |
|
From: Simeon W. <si...@cs...> - 2008-11-11 16:08:41
|
Stuart Lewis wrote: >> Please vote on using 413 and adding the error URI >> http://purl.org/net/sword/error/MaxUplaodSizeExceeded to cover the case where >> the package size exceeds the size stated in sword:maxUploadSize in the service >> document? +1 Both sound good to me. We plan to migrate the arXiv interface to SWORD1.3 in the near future (week or two) so I'm in favor of any tweaks happening quite soon. (Note typo in the error URI: ..Uplaod... -> ..Upload..) Cheers, Simeon |
|
From: Simeon W. <si...@cs...> - 2008-11-11 16:04:05
|
Stuart Lewis wrote: >>>>> So I would argue that the criterion for a SWORD package type are that: >>>>> >>>>> 1. the package type provides more specificity about the nature of a >>>>> package than a MIME type >>>>> 2. it is deemed useful by an implementor when creating a SWORD service >>>>> 3. sword-app-tech discussion list members agree with 2. >> In that case I'm going to unilaterally declare democracy in place and ask for >> votes on Ed's proposal for the criterion of a SWORD package type. Voting ends >> 2008-11-18 at 1030 GMT. If the proposal is successful I'll write it into the >> spec doc. +1 -- Simeon |
|
From: Stuart L. <sd...@ab...> - 2008-11-11 11:07:48
|
>>>> So I would argue that the criterion for a SWORD package type are that:
>>>>
>>>> 1. the package type provides more specificity about the nature of a
>>>> package than a MIME type
>>>> 2. it is deemed useful by an implementor when creating a SWORD service
>>>> 3. sword-app-tech discussion list members agree with 2.
>
> In that case I'm going to unilaterally declare democracy in place and ask for
> votes on Ed's proposal for the criterion of a SWORD package type. Voting ends
> 2008-11-18 at 1030 GMT. If the proposal is successful I'll write it into the
> spec doc.
+1
Stuart
_________________________________________________________________
Gwasanaethau Gwybodaeth Information Services
Prifysgol Aberystwyth Aberystwyth University
E-bost / E-mail: Stu...@ab...
Ffon / Tel: (01970) 622860
_________________________________________________________________
|
|
From: Stuart L. <sd...@ab...> - 2008-11-11 11:03:38
|
> Please vote on using 413 and adding the error URI > http://purl.org/net/sword/error/MaxUplaodSizeExceeded to cover the case where > the package size exceeds the size stated in sword:maxUploadSize in the service > document? +1 Stuart _________________________________________________________________ Gwasanaethau Gwybodaeth Information Services Prifysgol Aberystwyth Aberystwyth University E-bost / E-mail: Stu...@ab... Ffon / Tel: (01970) 622860 _________________________________________________________________ |
|
From: Jim D. <jim...@po...> - 2008-11-11 10:32:41
|
2008/11/11 Jim Downing <oj...@ca...> > Hi Stuart, > > 2008/11/10 Stuart Lewis <sd...@ab...> > >> I'm now starting to implement Error Documents in the Java SWORD library, >> so >> have been giving this failure case a bit more though. Should we add >> another >> Error URI (http://purl.org/net/sword/error/MaxUploadSizeExceeded or >> equivalent) to cover this case? > > Please vote on using 413 and adding the error URI http://purl.org/net/sword/error/MaxUplaodSizeExceeded to cover the case where the package size exceeds the size stated in sword:maxUploadSize in the service document? +1 Voting closes 2008-11-18 at 1030 GMT jim |
|
From: Jim D. <jim...@po...> - 2008-11-11 10:28:19
|
Hi all, 2008/11/11 Scott Yeadon <sco...@an...> > >> So I would argue that the criterion for a SWORD package type are that: > >> > >> 1. the package type provides more specificity about the nature of a > >> package than a MIME type > >> 2. it is deemed useful by an implementor when creating a SWORD service > >> 3. sword-app-tech discussion list members agree with 2. > In that case I'm going to unilaterally declare democracy in place and ask for votes on Ed's proposal for the criterion of a SWORD package type. Voting ends 2008-11-18 at 1030 GMT. If the proposal is successful I'll write it into the spec doc. +1 Best regards, jim |
|
From: Jim D. <oj...@ca...> - 2008-11-11 10:22:51
|
Hi Stuart, 2008/11/10 Stuart Lewis <sd...@ab...> > I'm now starting to implement Error Documents in the Java SWORD library, so > have been giving this failure case a bit more though. Should we add another > Error URI (http://purl.org/net/sword/error/MaxUploadSizeExceeded or > equivalent) to cover this case? Yes, sounds appropriate. > (Are we happy to accept small changes like this to 1.3 whilst we work > though > the implementations?) I'm happy to update the spec if the implementers are happy to make the changes. Perhaps agreeing on a hard freeze date for SWORD2 is the thing to do? jim > |
|
From: Scott Y. <sco...@an...> - 2008-11-11 00:26:32
|
Hi, >> So I would argue that the criterion for a SWORD package type are that: >> >> 1. the package type provides more specificity about the nature of a >> package than a MIME type >> 2. it is deemed useful by an implementor when creating a SWORD service >> 3. sword-app-tech discussion list members agree with 2. >> > > > > Sounds reasonable. > > Yes, I agree, I think that's about as detailed as is needed for now. Scott. |
|
From: Stuart L. <sd...@ab...> - 2008-11-10 20:14:19
|
Hi Jim, Thanks for your reply. I'm now starting to implement Error Documents in the Java SWORD library, so have been giving this failure case a bit more though. Should we add another Error URI (http://purl.org/net/sword/error/MaxUploadSizeExceeded or equivalent) to cover this case? (Are we happy to accept small changes like this to 1.3 whilst we work though the implementations?) Thanks, Stuart On 07/11/2008 16:56, "Jim Downing" <oj...@ca...> wrote: > I don't think 412's appropriate - there isn't a header that the client sets > that has evaluated to false in this case. > > Probably 413, then, since the request isn't syntactically incorrect. > > jim > > 2008/11/7 Stuart Lewis <sd...@ab...> >> Hi all, >> >> The v1.3 SWORD spec isn't clear about what response the server should return >> when the sword:maxUploadSize is breached. >> >> Which would be better: 412, 413, or something else? >> >> Thanks, >> >> >> Stuart >> >> >> >> 412 Precondition Failed >> The precondition given in one or more of the request-header fields evaluated >> to false when it was tested on the server. This response code allows the >> client to place preconditions on the current resource metainformation >> (header field data) and thus prevent the requested method from being applied >> to a resource other than the one intended. >> >> 413 Request Entity Too Large >> The server is refusing to process a request because the request entity is >> larger than the server is willing or able to process. The server MAY close >> the connection to prevent the client from continuing the request. >> >> If the condition is temporary, the server SHOULD include a Retry- After >> header field to indicate that it is temporary and after what time the client >> MAY try again. >> >> >> ------------------------------------------------------------------------- >> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >> Build the coolest Linux based applications with Moblin SDK & win great prizes >> Grand prize is a trip for two to an Open Source event anywhere in the world >> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >> _______________________________________________ >> sword-app-tech mailing list >> swo...@li... >> https://lists.sourceforge.net/lists/listinfo/sword-app-tech > > |
|
From: Julie A. <ja...@yo...> - 2008-11-10 15:41:51
|
I should warn people that the purl site is a little unstable today ... rest assured the purls have been assigned and the SWORD web site is very much live and stable. Julie Julie Allinson wrote: > Hi all, > > The SWORD specifications have been assigned persistent URIs: > SWORD profile 1.3: http://purl.org/net/sword > <http://purl.org/NET/sword> > SWORD types 1.0: http://purl.org/net/sword-types > <http://purl.org/NET/sword-types> > > The new home page for the SWORD activity is: > http://www.swordapp.org/ > > Some content relating to the original JISC-funded project will remain on > our wiki, but information about the SWORD specifications and related > documentation, is migrating to the SWORD web site. > > Best, > > Julie > > -- Julie Allinson <ja...@yo...> Digital Library Manager University Library & Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 434083 skype: j.allinson web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm -- |
|
From: Julie A. <ja...@yo...> - 2008-11-10 15:22:31
|
Hi all, The SWORD specifications have been assigned persistent URIs: SWORD profile 1.3: http://purl.oclc.org/net/sword <http://purl.oclc.org/NET/sword> SWORD types 1.0: http://purl.oclc.org/net/sword-types <http://purl.oclc.org/NET/sword-types> The new home page for the SWORD activity is: http://www.swordapp.org/ Some content relating to the original JISC-funded project will remain on our wiki, but information about the SWORD specifications and related documentation, is migrating to the SWORD web site. Best, Julie -- Julie Allinson <ja...@yo...> Digital Library Manager University Library & Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 434083 skype: j.allinson web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm -- |
|
From: Ed S. <eh...@po...> - 2008-11-10 11:13:56
|
On Mon, Nov 10, 2008 at 5:23 AM, Jim Downing <jim...@po...> wrote: > Eventually the spec will be hosted on swordapp.org and redirected from > purl.org. The use of my home directory was a stop gap only made necessary > because some Mordac at sourceforge has decided to make uploading to the > project web space more difficult than I could be bothered with. Cool. Is there a purl already for the v1.3 spec? > I think the fact that Scott and you are prominent in this discussion is a > strong indication - the proof of the pudding will come after the end of the > current JISC SWORD2 project. Yes, and Simeon's involvement at arxiv.org is encouraging too [1]. I imagine we'd all like to see more of this extra-JISC collaboration. My guess is that putting the spec somewhere that "seems" stable will help further this goal. Anyhow, you all have done really nice work so far. Hat's off to you. //Ed [1] http://tinyurl.com/6arr94 |
|
From: Jim D. <jim...@po...> - 2008-11-10 10:23:47
|
Hi Ed, 2008/11/7 Ed Summers <eh...@po...> > On Thu, Nov 6, 2008 at 9:03 AM, Jim Downing <jim...@po...> wrote: > > I had intended that this should simply be a unique identifier for the > type - > > if it's convenient for people to use the namespace / whatever then that's > > fine, but I don't see a lot of utility in enforcing any additional > semantics > > beyond that. > > > > I've redrafted: > > http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0_2008-11-06.html<http://wwmm.ch.cam.ac.uk/%7Eojd20/sword-type-1.0_2008-11-06.html> > > Looks good to me. I particularly like the language about a package > identifier not needing to point to an XML Namespace. Would it be > appropriate to reference RFC3986 and remove the other non-relevant > references? Yes, absolutely - I hadn't done the reference check pass yet. > > What do you see as constituting a type? e.g. METS? METS+profile? METS + > > profile + metadata schemas used? Is the purpose of the content a valid > > aspect of a type? Anything anyone wants to use the field for? > > It seems to me that SWORD package types were deemed necessary because > MIME types weren't enough right? For example, one could zip up a METS > package and an IMS Common Cartridge package and submit both as a > application/zip, and the SWORD service would have some difficulty in > distinguishing between the two. > > So the SWORD package type allows the client and the server to agree > about the precise structure of a package in situations where agreement > about the MIME type isn't enough. That being said, just saying a > package is say METS, or even a particular METS profile may not say too > much about where say the METS xml is to be found once a package is > unzipped. > > So I would argue that the criterion for a SWORD package type are that: > > 1. the package type provides more specificity about the nature of a > package than a MIME type > 2. it is deemed useful by an implementor when creating a SWORD service > 3. sword-app-tech discussion list members agree with 2. Sounds reasonable. > It's outside the scope of the current JISC funding, and would certainly > > require an amount of resource to achieve. I have to admit to being a > little > > less convinced by the need for standardization in this instance, but I'm > > open to being persuaded. > > That makes sense. Honestly, I'd just like to see a SWORD 1.3 URI that > looks a bit more official and stable than: > > http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0-20081010.html<http://wwmm.ch.cam.ac.uk/%7Eojd20/sword-type-1.0-20081010.html> Eventually the spec will be hosted on swordapp.org and redirected from purl.org. The use of my home directory was a stop gap only made necessary because some Mordac at sourceforge has decided to make uploading to the project web space more difficult than I could be bothered with. > You could always submit it as a IETF draft, I don't think there's much > overhead to that. I think it would be valuable to adopters to see > SWORD swimming without the JISC life-jacket. But I'm not sure what the > best way to do that is. I think the fact that Scott and you are prominent in this discussion is a strong indication - the proof of the pudding will come after the end of the current JISC SWORD2 project. > I'm willing to lend a hand at helping out if > you need any. Appreciated. Best regards, jim |
|
From: Ed S. <eh...@po...> - 2008-11-07 20:54:42
|
On Thu, Nov 6, 2008 at 9:03 AM, Jim Downing <jim...@po...> wrote: > I had intended that this should simply be a unique identifier for the type - > if it's convenient for people to use the namespace / whatever then that's > fine, but I don't see a lot of utility in enforcing any additional semantics > beyond that. > > I've redrafted: > http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0_2008-11-06.html Looks good to me. I particularly like the language about a package identifier not needing to point to an XML Namespace. Would it be appropriate to reference RFC3986 and remove the other non-relevant references? > Does anyone have suggestions on how the authority control could be done? > Popular vote of anyone who's interested (a la Apache)? +1 > What do you see as constituting a type? e.g. METS? METS+profile? METS + > profile + metadata schemas used? Is the purpose of the content a valid > aspect of a type? Anything anyone wants to use the field for? It seems to me that SWORD package types were deemed necessary because MIME types weren't enough right? For example, one could zip up a METS package and an IMS Common Cartridge package and submit both as a application/zip, and the SWORD service would have some difficulty in distinguishing between the two. So the SWORD package type allows the client and the server to agree about the precise structure of a package in situations where agreement about the MIME type isn't enough. That being said, just saying a package is say METS, or even a particular METS profile may not say too much about where say the METS xml is to be found once a package is unzipped. So I would argue that the criterion for a SWORD package type are that: 1. the package type provides more specificity about the nature of a package than a MIME type 2. it is deemed useful by an implementor when creating a SWORD service 3. sword-app-tech discussion list members agree with 2. > It's outside the scope of the current JISC funding, and would certainly > require an amount of resource to achieve. I have to admit to being a little > less convinced by the need for standardization in this instance, but I'm > open to being persuaded. That makes sense. Honestly, I'd just like to see a SWORD 1.3 URI that looks a bit more official and stable than: http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0-20081010.html You could always submit it as a IETF draft, I don't think there's much overhead to that. I think it would be valuable to adopters to see SWORD swimming without the JISC life-jacket. But I'm not sure what the best way to do that is. I'm willing to lend a hand at helping out if you need any. //Ed |
|
From: Jim D. <oj...@ca...> - 2008-11-07 16:56:49
|
I don't think 412's appropriate - there isn't a header that the client sets that has evaluated to false in this case. Probably 413, then, since the request isn't syntactically incorrect. jim 2008/11/7 Stuart Lewis <sd...@ab...> > Hi all, > > The v1.3 SWORD spec isn't clear about what response the server should > return > when the sword:maxUploadSize is breached. > > Which would be better: 412, 413, or something else? > > Thanks, > > > Stuart > > > > 412 Precondition Failed > The precondition given in one or more of the request-header fields > evaluated > to false when it was tested on the server. This response code allows the > client to place preconditions on the current resource metainformation > (header field data) and thus prevent the requested method from being > applied > to a resource other than the one intended. > > 413 Request Entity Too Large > The server is refusing to process a request because the request entity is > larger than the server is willing or able to process. The server MAY close > the connection to prevent the client from continuing the request. > > If the condition is temporary, the server SHOULD include a Retry- After > header field to indicate that it is temporary and after what time the > client > MAY try again. > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win great > prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > |
|
From: Stuart L. <sd...@ab...> - 2008-11-07 15:44:30
|
Hi all, The v1.3 SWORD spec isn't clear about what response the server should return when the sword:maxUploadSize is breached. Which would be better: 412, 413, or something else? Thanks, Stuart 412 Precondition Failed The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended. 413 Request Entity Too Large The server is refusing to process a request because the request entity is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. |
|
From: Scott Y. <sco...@an...> - 2008-11-06 22:06:06
|
Hi Jim, Jim Downing wrote: > I've redrafted: > http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0_2008-11-06.html > <http://wwmm.ch.cam.ac.uk/%7Eojd20/sword-type-1.0_2008-11-06.html> > > >> The process for adding new types I guess depends on whether this is > >> going to be a managed registry post-SWORD2, but a minimus set of > >> requirements could be specified in order to create a new > registry entry > >> e.g. name, description, namespace URI, specification URI, > contact point, > >> version, other? > >> > > > > I guess I would like to see some text added about how to get a > package > > format into the list. Perhaps something as simple as emailing this > > discussion list? > > > I think that would be the simplest way, and hence the best way to > start. Does anyone have suggestions on how the authority control could > be done? Popular vote of anyone who's interested (a la Apache)? Popular vote seems fine to start with > > What do you see as constituting a type? e.g. METS? METS+profile? METS > + profile + metadata schemas used? In a METS context it's likely to be a profile (a profile *should* specify any limitations or extension schema used so would cover all the above. To me a type is a consistent modelling of content (either general content or a specific class of content) which is documented to an extent that others can either develop against it or others are able to determine whether it might be able to be applied in their local context > Is the purpose of the content a valid aspect of a type? Probably not? - this would be covered in the docs associated with a given type wouldn't it (i.e. the METS profile or other supporting docs)? The purpose may also depend on who/how the type is being used so may not be static or have only one purpose. > Anything anyone wants to use the field for? > jim > |
|
From: Ed S. <eh...@po...> - 2008-11-06 21:15:19
|
I was wondering, does the Content-Disposition example in the SWORD doc [1] need to include a disposition-type like 'attachment'? """ POST /deposit/ndiipp/package:123 HTTP/1.1 Host: www.loc.gov Content-Type: application/octet-stream Content-Length: nnn Content-Disposition: attachment; filename=data/something/else.txt ...binary data .. """ The BNF in RFC2818 [2] (which SWORD references) seems to indicate that it's required. Or does the SWORD usage follow in the wild usage? """ disposition := "Content-Disposition" ":" disposition-type *(";" disposition-parm) disposition-type := "inline" / "attachment" / extension-token ; values are not case-sensitive disposition-parm := filename-parm / creation-date-parm / modification-date-parm / read-date-parm / size-parm / parameter filename-parm := "filename" "=" value creation-date-parm := "creation-date" "=" quoted-date-time modification-date-parm := "modification-date" "=" quoted-date-time read-date-parm := "read-date" "=" quoted-date-time size-parm := "size" "=" 1*DIGIT quoted-date-time := quoted-string ; contents MUST be an RFC 822 `date-time' ; numeric timezones (+HHMM or -HHMM) MUST be used """ //Ed [1] http://wwmm.ch.cam.ac.uk/~ojd20/sword-profile-1.3-20081007.html [2] http://www.ietf.org/rfc/rfc2818.txt |
|
From: Julie A. <ja...@yo...> - 2008-11-06 14:35:28
|
Jim Downing wrote: > Hi all, > > 2008/11/6 Scott Yeadon <sco...@an... > <mailto:sco...@an...>> > > Ed Summers wrote: > > On Thu, Oct 30, 2008 at 7:49 PM, Scott Yeadon > <sco...@an... <mailto:sco...@an...>> wrote: > > > >> On the SWORD types document I think it would also be useful to > specify > >> the X-Packaging and acceptPackaging and packaging values > associated with > >> all registered values to remove any possible discrepancies between > >> implementations. Probably also need to be clearer on the "URI" > column - > >> i.e. namespace URI or ?? > >> > > > > Aren't the values the URIs in the Package Types Document, e.g. > > http://www.loc.gov/METS/ for METS? > > > > > That METS URL is used as an XML namespace for METS and also is the > location for the various METS specs, profiles etc. The IMS 1.1 and 1.2 > link to an IMS "Document not found" page. I was just trying to > ascertain > what the intent of this URI column is. If the SWORD Types Registry > is to > provide a useful service for SWORD users (for registration and > reference), then the requirements of the package metadata should be > unambiguous. My point is I think the meaning and content of format > registry entries needs to be clear and consistent to be useful - if I > see a column called "URI" does it contain the package format's XML > namespace, homepage, application profile, ???. > > > I had intended that this should simply be a unique identifier for the > type - if it's convenient for people to use the namespace / whatever > then that's fine, but I don't see a lot of utility in enforcing any > additional semantics beyond that. > > I've redrafted: > http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0_2008-11-06.html > <http://wwmm.ch.cam.ac.uk/%7Eojd20/sword-type-1.0_2008-11-06.html> > > >> The process for adding new types I guess depends on whether this is > >> going to be a managed registry post-SWORD2, but a minimus set of > >> requirements could be specified in order to create a new > registry entry > >> e.g. name, description, namespace URI, specification URI, > contact point, > >> version, other? > >> > > > > I guess I would like to see some text added about how to get a > package > > format into the list. Perhaps something as simple as emailing this > > discussion list? > > > I think that would be the simplest way, and hence the best way to > start. Does anyone have suggestions on how the authority control could > be done? Popular vote of anyone who's interested (a la Apache)? > > What do you see as constituting a type? e.g. METS? METS+profile? METS > + profile + metadata schemas used? Is the purpose of the content a > valid aspect of a type? Anything anyone wants to use the field for? > > > On the subject of URIs are there any plans for the v1.3 spec to move > > to somewhere a bit more official sounding? At one point I heard Jim > > suggest that pushing SWORD to the IETF as an RFC might be a > > possibility. > > It's outside the scope of the current JISC funding, and would > certainly require an amount of resource to achieve. I have to admit > to being a little less convinced by the need for standardization in > this instance, but I'm open to being persuaded. It will at least be assigned a PURL, which will give it a more official and persistent URL. Julie > > jim > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ------------------------------------------------------------------------ > > _______________________________________________ > sword-app-tech mailing list > swo...@li... > https://lists.sourceforge.net/lists/listinfo/sword-app-tech > -- Julie Allinson <ja...@yo...> Digital Library Manager University Library & Archives, J.B. Morrell Library University of York, Heslington, York, YO10 5DD, UK tel: ++44 (0) 1904 434083 skype: j.allinson web: http://www.york.ac.uk/services/library/elibrary/digitallibrary.htm -- |
|
From: Jim D. <jim...@po...> - 2008-11-06 14:03:20
|
Hi all, 2008/11/6 Scott Yeadon <sco...@an...> > Ed Summers wrote: > > On Thu, Oct 30, 2008 at 7:49 PM, Scott Yeadon <sco...@an...> > wrote: > > > >> On the SWORD types document I think it would also be useful to specify > >> the X-Packaging and acceptPackaging and packaging values associated with > >> all registered values to remove any possible discrepancies between > >> implementations. Probably also need to be clearer on the "URI" column - > >> i.e. namespace URI or ?? > >> > > > > Aren't the values the URIs in the Package Types Document, e.g. > > http://www.loc.gov/METS/ for METS? > > > > > That METS URL is used as an XML namespace for METS and also is the > location for the various METS specs, profiles etc. The IMS 1.1 and 1.2 > link to an IMS "Document not found" page. I was just trying to ascertain > what the intent of this URI column is. If the SWORD Types Registry is to > provide a useful service for SWORD users (for registration and > reference), then the requirements of the package metadata should be > unambiguous. My point is I think the meaning and content of format > registry entries needs to be clear and consistent to be useful - if I > see a column called "URI" does it contain the package format's XML > namespace, homepage, application profile, ???. I had intended that this should simply be a unique identifier for the type - if it's convenient for people to use the namespace / whatever then that's fine, but I don't see a lot of utility in enforcing any additional semantics beyond that. I've redrafted: http://wwmm.ch.cam.ac.uk/~ojd20/sword-type-1.0_2008-11-06.html >> The process for adding new types I guess depends on whether this is > >> going to be a managed registry post-SWORD2, but a minimus set of > >> requirements could be specified in order to create a new registry entry > >> e.g. name, description, namespace URI, specification URI, contact point, > >> version, other? > >> > > > > I guess I would like to see some text added about how to get a package > > format into the list. Perhaps something as simple as emailing this > > discussion list? > I think that would be the simplest way, and hence the best way to start. Does anyone have suggestions on how the authority control could be done? Popular vote of anyone who's interested (a la Apache)? What do you see as constituting a type? e.g. METS? METS+profile? METS + profile + metadata schemas used? Is the purpose of the content a valid aspect of a type? Anything anyone wants to use the field for? > On the subject of URIs are there any plans for the v1.3 spec to move > to somewhere a bit more official sounding? At one point I heard Jim > suggest that pushing SWORD to the IETF as an RFC might be a > possibility. It's outside the scope of the current JISC funding, and would certainly require an amount of resource to achieve. I have to admit to being a little less convinced by the need for standardization in this instance, but I'm open to being persuaded. jim |
|
From: Jim D. <jim...@po...> - 2008-11-06 08:23:36
|
Hi Scott, Ed, 2008/11/6 Scott Yeadon <sco...@an...> > Ed Summers wrote: > > On Thu, Oct 30, 2008 at 7:49 PM, Scott Yeadon <sco...@an...> > wrote: > > > >> On the SWORD types document I think it would also be useful to specify > >> the X-Packaging and acceptPackaging and packaging values associated with > >> all registered values to remove any possible discrepancies between > >> implementations. Probably also need to be clearer on the "URI" column - > >> i.e. namespace URI or ?? > >> > > > > Aren't the values the URIs in the Package Types Document, e.g. > > http://www.loc.gov/METS/ for METS? > > > > > That METS URL is used as an XML namespace for METS and also is the > location for the various METS specs, profiles etc. The IMS 1.1 and 1.2 > link to an IMS "Document not found" page. I was just trying to ascertain > what the intent of this URI column is. If the SWORD Types Registry is to > provide a useful service for SWORD users (for registration and > reference), then the requirements of the package metadata should be > unambiguous. My point is I think the meaning and content of format > registry entries needs to be clear and consistent to be useful - if I > see a column called "URI" does it contain the package format's XML > namespace, homepage, application profile, ???. My intention was that the URI would be simply an identifier and that there would be a link to useful doco in the registry. I'll add some text to explain it better. jim |
|
From: Scott Y. <sco...@an...> - 2008-11-06 03:47:08
|
Ed Summers wrote: > On Thu, Oct 30, 2008 at 7:49 PM, Scott Yeadon <sco...@an...> wrote: > >> On the SWORD types document I think it would also be useful to specify >> the X-Packaging and acceptPackaging and packaging values associated with >> all registered values to remove any possible discrepancies between >> implementations. Probably also need to be clearer on the "URI" column - >> i.e. namespace URI or ?? >> > > Aren't the values the URIs in the Package Types Document, e.g. > http://www.loc.gov/METS/ for METS? > > That METS URL is used as an XML namespace for METS and also is the location for the various METS specs, profiles etc. The IMS 1.1 and 1.2 link to an IMS "Document not found" page. I was just trying to ascertain what the intent of this URI column is. If the SWORD Types Registry is to provide a useful service for SWORD users (for registration and reference), then the requirements of the package metadata should be unambiguous. My point is I think the meaning and content of format registry entries needs to be clear and consistent to be useful - if I see a column called "URI" does it contain the package format's XML namespace, homepage, application profile, ???. >> The process for adding new types I guess depends on whether this is >> going to be a managed registry post-SWORD2, but a minimus set of >> requirements could be specified in order to create a new registry entry >> e.g. name, description, namespace URI, specification URI, contact point, >> version, other? >> > > I guess I would like to see some text added about how to get a package > format into the list. Perhaps something as simple as emailing this > discussion list? > > On the subject of URIs are there any plans for the v1.3 spec to move > to somewhere a bit more official sounding? At one point I heard Jim > suggest that pushing SWORD to the IETF as an RFC might be a > possibility. > > //Ed > > |
|
From: Ed S. <eh...@po...> - 2008-11-06 03:22:58
|
On Thu, Oct 30, 2008 at 7:49 PM, Scott Yeadon <sco...@an...> wrote: > On the SWORD types document I think it would also be useful to specify > the X-Packaging and acceptPackaging and packaging values associated with > all registered values to remove any possible discrepancies between > implementations. Probably also need to be clearer on the "URI" column - > i.e. namespace URI or ?? Aren't the values the URIs in the Package Types Document, e.g. http://www.loc.gov/METS/ for METS? > The process for adding new types I guess depends on whether this is > going to be a managed registry post-SWORD2, but a minimus set of > requirements could be specified in order to create a new registry entry > e.g. name, description, namespace URI, specification URI, contact point, > version, other? I guess I would like to see some text added about how to get a package format into the list. Perhaps something as simple as emailing this discussion list? On the subject of URIs are there any plans for the v1.3 spec to move to somewhere a bit more official sounding? At one point I heard Jim suggest that pushing SWORD to the IETF as an RFC might be a possibility. //Ed |
13 messages has been excluded from this view by a project administrator.
