Re: [CODE4LIB] registering info: uris?
At Fri, 27 Mar 2009 20:56:42 -0400, Ross Singer wrote: So, in a what is probably a vain attempt to put this debate to rest, I created a partial redirect PURL for sudoc: http://purl.org/NET/sudoc/ If you pass it any urlencoded sudoc string, you'll be redirected to the GPO's Aleph catalog that searches the sudoc field for that string. http://purl.org/NET/sudoc/E%202.11/3:EL%202 should take you to: http://catalog.gpo.gov/F/?func=find-cccl_term=GVD%3DE%202.11/3:EL%202 There, Jonathan, you have a dereferenceable URI structure that you A) don't have to worry about pointing at something misleading B) don't have to maintain (although I'll be happy to add whoever as a maintainer to this PURL) If the GPO ever has a better alternative, we just point the PURL at it in the future. Beautiful work, Ross. Thank you. best, Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpC8fHWXKSFo.pgp Description: PGP signature
Re: [CODE4LIB] registering info: uris?
From: Erik Hetzner erik.hetz...@ucop.edu I believe that registering a domain would be less work than going through an info URI registration process, but I don’t know how difficult the info URI registration process would be (thus bringing the conversation full circle). [1] Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. --Ray
Re: [CODE4LIB] registering info: uris?
That's got a session token in it, Andrew. Not to mention it will no longer resolve to anything whenever GPO changes their ILS platform. You guys don't seem to believe that I've spent a chunk of time investigating all this stuff before I even brought it up here. I did, really! Jonathan Houghton,Andrew wrote: From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Friday, March 27, 2009 6:09 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? If GPO had a system where I could resolve Sudoc identifiers, then this whole problem would be solved right there, I wouldn't need to go any further, I'd just use the http URI's associated with that system as identifiers! This whole problem statement is because GPO does not provide any persistent URIs for sudoc's in the first place, right? With a little Googling how about this: sudoc: E 2.11/3:EL 2 http://catalog.gpo.gov/F/FIBJ8T23DNC33L6KEDYR7Q8Q3MF6BI9H7Q5XPG4KB3N57HX35X-17544?func=scanscan_code=SUDscan_start=E+2.11%2F3%3AEL+2 looks like the param scan_start= holds the sudoc number. Sure it gives you other results, but its might work for your purposes. Seems like they are creating bad HTTP responses since Fiddler throws an protocol violation because they do not end the HTTP headers with CR,LF,CR,LF and instead use LF,LF... Andy.
Re: [CODE4LIB] registering info: uris?
I think this is a good point. Ray Denenberg, Library of Congress wrote: From: Erik Hetzner erik.hetz...@ucop.edu I believe that registering a domain would be less work than going through an info URI registration process, but I don’t know how difficult the info URI registration process would be (thus bringing the conversation full circle). [1] Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. --Ray
Re: [CODE4LIB] registering info: uris?
So is there anything wrong with having both that http-based PURL URI available, AND an info uri? Not only available, but in common use? It gets complicated thinking about these things. There are potentially several things wrong with it. Jonathan Ross Singer wrote: On Mon, Mar 30, 2009 at 10:12 AM, Ray Denenberg, Library of Congress r...@loc.gov wrote: Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. Avoiding the religious debate that I *think* Ray is referring to (http vs. info URIs) and instead raising a different religious debate... I don't have a problem with going through this process to formalize an info URI once a domain has been thoroughly evaluated and worked out, but it throws any and all sense of 'agility' out the window and in many cases, kills any potential hope of actually seeing these identifiers at all. The upfront costs are just too high, the details too arcane and the payoff too low for somebody like Jonathan to solve an immediate problem. I'm not saying we shouldn't think these things out beforehand; recklessness, of course, is not the answer. Perfection, however, being the enemy of the good makes me think the info:uri process isn't a particularly good or efficient one for working with real world problems. Add to it that nobody gives a damn about info:uris outside of libraries, it seems like a total waste of energy. Although I suppose that strays back into the original religious debate. -Ross.
Re: [CODE4LIB] registering info: uris?
Jonathan Rochkind writes: So is there anything wrong with having both that http-based PURL URI available, AND an info uri? Not only available, but in common use? Yes, of course! You don't want _two_ vocabularies of URIs for SUDOCs! _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ I am not so much afraid of death, as ashamed thereof -- Sir Thomas Browne (1605-1682), English physician and author.
Re: [CODE4LIB] registering info: uris?
There should be no issue with having both, mainly because like I mentioned earlier, nobody cares about info:uris. Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. As Ray mentioned earlier in this thread, there is absolutely no reason an object cannot have multiple identifiers, especially if they stand to serve somewhat different purposes. I guess the way I look at it is: 1. The web is not going to wait for info:uris 2. The web is not going to use info:uris anyway, even after we've exhausted all of the corner cases and come up with the perfect URI model for a given domain, *because there's nothing the web can do with them anyway*. -Ross. On Mon, Mar 30, 2009 at 10:55 AM, Jonathan Rochkind rochk...@jhu.edu wrote: So is there anything wrong with having both that http-based PURL URI available, AND an info uri? Not only available, but in common use? It gets complicated thinking about these things. There are potentially several things wrong with it. Jonathan Ross Singer wrote: On Mon, Mar 30, 2009 at 10:12 AM, Ray Denenberg, Library of Congress r...@loc.gov wrote: Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. Avoiding the religious debate that I *think* Ray is referring to (http vs. info URIs) and instead raising a different religious debate... I don't have a problem with going through this process to formalize an info URI once a domain has been thoroughly evaluated and worked out, but it throws any and all sense of 'agility' out the window and in many cases, kills any potential hope of actually seeing these identifiers at all. The upfront costs are just too high, the details too arcane and the payoff too low for somebody like Jonathan to solve an immediate problem. I'm not saying we shouldn't think these things out beforehand; recklessness, of course, is not the answer. Perfection, however, being the enemy of the good makes me think the info:uri process isn't a particularly good or efficient one for working with real world problems. Add to it that nobody gives a damn about info:uris outside of libraries, it seems like a total waste of energy. Although I suppose that strays back into the original religious debate. -Ross.
Re: [CODE4LIB] registering info: uris?
On Mon, 2009-03-30 at 16:08 +0100, Ross Singer wrote: There should be no issue with having both, mainly because like I mentioned earlier, nobody cares about info:uris. s/nobody cares/the web doesn't care/ 'The Web' isn't the only use case. There are plenty of reasons for having non dereferencable identifiers, for example for things which do not have a web representation, or have too many web representations to make favouring one over another a waste of time. For example abstract concepts. I guess the way I look at it is: 1. The web is not going to wait for info:uris 2. The web is not going to use info:uris anyway, even after we've exhausted all of the corner cases and come up with the perfect URI model for a given domain, *because there's nothing the web can do with them anyway*. Working As Intended. If you want an identifier that *explicitly* cannot be dereferenced, then info URIs are a good choice. If you want one that can be dereferenced to some representation of the identified object, then HTTP is the only choice. Rob
Re: [CODE4LIB] registering info: uris?
On Mon, Mar 30, 2009 at 11:18 AM, Ray Denenberg, Library of Congress r...@loc.gov wrote: Nor do people outside of libraries care about identifiers. Except, of course, for Tim Berners-Lee and anybody who listens to him: http://www.w3.org/DesignIssues/LinkedData.html -Ross.
Re: [CODE4LIB] registering info: uris?
From: Ross Singer rossfsin...@gmail.com nobody gives a damn about info:uris outside of libraries, Nor do people outside of libraries care about identifiers. --Ray
Re: [CODE4LIB] registering info: uris?
Ross Singer writes: There should be no issue with having both, mainly because like I mentioned earlier, nobody cares about info:uris. Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ You can never go back -- only forwards, or stand still.
Re: [CODE4LIB] registering info: uris?
On Mon, Mar 30, 2009 at 11:17 AM, Rob Sanderson azar...@liverpool.ac.uk wrote: If you want an identifier that *explicitly* cannot be dereferenced, then info URIs are a good choice. If you want one that can be dereferenced to some representation of the identified object, then HTTP is the only choice. Yes, I completely agree with this, which is why I think it *has* to be no problem that both info:uris and http uris can co-exist. I'm not entirely sure of the use case of identifiers that cannot be derefenced, I mean, I'm sure they exist (driver's license numbers, might be an example), but I don't see anything in the current info:uri registry wouldn't necessarily be better served with an HTTP uri. -Ross.
Re: [CODE4LIB] registering info: uris?
Because the ability to de-reference seems to be the main reason to use an HTTP URI as an identifier, and the main reason that some people prefer an HTTP URI as an identifier to an info: URI. Jonathan Mike Taylor wrote: Ross Singer writes: There should be no issue with having both, mainly because like I mentioned earlier, nobody cares about info:uris. Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ You can never go back -- only forwards, or stand still.
Re: [CODE4LIB] registering info: uris?
Jonathan Rochkind writes: Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. Because the ability to de-reference seems to be the main reason to use an HTTP URI as an identifier, and the main reason that some people prefer an HTTP URI as an identifier to an info: URI. That looks like a plain and simple confusion to me. Identifiers and addresses are two quite different things. That they happen to be expressed in similar or even identical syntax is an accident of history. Surely our experiences with XML namespaces (which do not exist) have taught us that? _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- Klingon Programming Mantra
Re: [CODE4LIB] registering info: uris?
This is a long argument that's been going on in other communities for a long time, Mike. I can see both sides. Jonathan Mike Taylor wrote: Jonathan Rochkind writes: Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. Because the ability to de-reference seems to be the main reason to use an HTTP URI as an identifier, and the main reason that some people prefer an HTTP URI as an identifier to an info: URI. That looks like a plain and simple confusion to me. Identifiers and addresses are two quite different things. That they happen to be expressed in similar or even identical syntax is an accident of history. Surely our experiences with XML namespaces (which do not exist) have taught us that? _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ Our users will know fear and cower before our software! Ship it! Ship it and let them flee like the dogs they are! -- Klingon Programming Mantra
Re: [CODE4LIB] registering info: uris?
Houghton,Andrew writes: Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. Exactly, that is what people don't understand about RFC 3986. URIs are just identifiers and have nothing to do with dereferencing. Dereferencing only comes into play when the URI is used with an actual protocol like HTTP. The only thing the http:, e.g., URI scheme, starting the URI tells you is what the syntax of the rest of the URI looks like. This is where the authors of info URIs missed the boat. They conflated the URI scheme, e.g., http:, with dereferencing and used it as a justification for a new URI scheme. The authors were told of that misconception before info became an RFC by both the IETF and W3C [...] ... and by me, for what's it's worth (remember, Ray? :-)) ... [...], but they decided to proceed anyway creating another library specific standard that no one else will use. If people would just follow the prescribed practice by the W3C: http://www.w3.org/TR/webarch/ Architecture of the Web says: 2.3.1. URI aliases Best practice: A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource. 2.4. URI Schemes Best practice: A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. True -- it's all there. The problem is that, after setting up a non-dereferencable http: URI to name something like an XML namespace or a CQL context set, it's just so darned _tempting_ to put something explanatory at the location which happens to be indicated by that URI :-) _/|____ /o ) \/ Mike Taylorm...@indexdata.comhttp://www.miketaylor.org.uk )_v__/\ You can also join us online at www.msnbc.com. You know, I'm always afraid I'm going to say too many Ws. -- NBC news anchorman Tom Brokaw.
Re: [CODE4LIB] registering info: uris?
Meanwhile, there are others who are arguing just as strongly that identifiers should _always_ be resolvable. Seriously, this debate has been going on in a while in other forums, we aren't the first to have it. I can see both sides, neither seems obviously right to me. Which I guess suggests that we need room for both resolvable identifiers and non-resolvable identifiers. (And then people will start arguing on whether http uri's provide all the room we need for non-resolvable ones or not. That argument has been had before too, and I see both sides there too!) Some hints of the existing argument in other forums can be found in this post by Stu Weibel, and the other posts it links to. http://weibel-lines.typepad.com/weibelines/2006/08/uncoupling_iden.html Jonathan Houghton,Andrew wrote: From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Mike Taylor Sent: Monday, March 30, 2009 11:30 AM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? Ross Singer writes: There should be no issue with having both, mainly because like I mentioned earlier, nobody cares about info:uris. Take, for instance, DOIs. What do you see in the wild? Do you ever see info:uris (except in OpenURLs)? If you don't see http://dx.doi.org/ URIs you generally see doi:10... URIs. It seems like having http and info URIs would *have* to be fine, since info:uris *not being dereferenceable* are far less useful (I won't go so far as 'useless') on the web, which is where all this is happening. What on earth does dereferencing have to do with this? We're talking about an identifier. Exactly, that is what people don't understand about RFC 3986. URIs are just identifiers and have nothing to do with dereferencing. Dereferencing only comes into play when the URI is used with an actual protocol like HTTP. The only thing the http:, e.g., URI scheme, starting the URI tells you is what the syntax of the rest of the URI looks like. This is where the authors of info URIs missed the boat. They conflated the URI scheme, e.g., http:, with dereferencing and used it as a justification for a new URI scheme. The authors were told of that misconception before info became an RFC by both the IETF and W3C, but they decided to proceed anyway creating another library specific standard that no one else will use. If people would just follow the prescribed practice by the W3C: http://www.w3.org/TR/webarch/ Architecture of the Web says: 2.3.1. URI aliases Best practice: A URI owner SHOULD NOT associate arbitrarily different URIs with the same resource. 2.4. URI Schemes Best practice: A specification SHOULD reuse an existing URI scheme (rather than create a new one) when it provides the desired properties of identifiers and their relation to resources. Quote: While Web architecture allows the definition of new schemes, introducing a new scheme is costly. Many aspects of URI processing are scheme-dependent, and a large amount of deployed software already processes URIs of well-known schemes. Introducing a new URI scheme requires the development and deployment not only of client software to handle the scheme, but also of ancillary agents such as gateways, proxies, and caches. See [RFC2718] for other considerations and costs related to URI scheme design. http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 This tag finding pretty much debunks all the reasons given by the info URI authors for creating a new URI scheme. I think Erik Hetzner also referenced it in his posts. Andy.
Re: [CODE4LIB] registering info: uris?
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Mike Taylor Sent: Monday, March 30, 2009 12:15 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? The problem is that, after setting up a non-dereferencable http: URI to name something like an XML namespace or a CQL context set, it's just so darned _tempting_ to put something explanatory at the location which happens to be indicated by that URI :-) and that is what you are suppose to do... Having a representation of the thing is useful and is what makes the Web and any other hypertext system useful. Andy.
Re: [CODE4LIB] registering info: uris?
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Monday, March 30, 2009 12:16 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? Some hints of the existing argument in other forums can be found in this post by Stu Weibel, and the other posts it links to. http://weibel-lines.typepad.com/weibelines/2006/08/uncoupling_iden.html Unfortunately, Stu is an author of the info URI specification and the he makes the same arguments that they made for the justification of the info URI RFC which has been debunked by the W3C: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Andy.
Re: [CODE4LIB] registering info: uris?
At Mon, 30 Mar 2009 10:12:39 -0400, Ray Denenberg, Library of Congress wrote: Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. Reading over your previous message regarding mapping SuDocs syntax to URI syntax, I completely agree about the necessity of clarifying these rules. But I was referring to the bureaucratic overhead (little thought it may be) in registering an info: URI. This overhead may or may not be useful, but it is there, including a submission process, internal review, public comments (according the draft info URI registry policy). -Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpz1Vry1WFt3.pgp Description: PGP signature
Re: [CODE4LIB] registering info: uris?
I agree with this as well. I guess it just depends on whether you think this needs to be done prior to facitating the process to mint URIs or after. The advantage to the former is that it will actually get documented. Speaking of, if anybody wants to help formalize this for the purl method, I'll be happy to work on it with somebody. -Ross. On Mon, Mar 30, 2009 at 1:40 PM, Erik Hetzner erik.hetz...@ucop.edu wrote: At Mon, 30 Mar 2009 10:12:39 -0400, Ray Denenberg, Library of Congress wrote: Leaving aside religious issues I just want to be sure we're clear on one point: the work required for the info URI process is exactly the amount of work required, no more no less. It forces you to specify clear syntax and semantics, normalization (if applicable), etc. If you go a different route because it's less work, then you're probably avoiding doing work that needs to be done. Reading over your previous message regarding mapping SuDocs syntax to URI syntax, I completely agree about the necessity of clarifying these rules. But I was referring to the bureaucratic overhead (little thought it may be) in registering an info: URI. This overhead may or may not be useful, but it is there, including a submission process, internal review, public comments (according the draft info URI registry policy). -Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3
Re: [CODE4LIB] registering info: uris?
It's interesting that there are at least three, if not four, viewpoints being represented in this conversation. The first argument is over whether all identifiers should be resolvable or not. While I respect the argument that it's _useful_ to have resolvable (to something) identifiers , I think it's an unneccesary limitation to say that all identifiers _must_ be resolvable. There are cases where it is infeasible on a business level to support resolvability. It may be for as simple a reason as that the body who actually maintains the identifiers is not interested in providing such at present. You can argue that they _ought_ to be, but back in the real world, should that stand as a barrier to anyone else using URI identifiers based on that particular identifier system? Wouldn't it be better if it didn't have to be? [ Another obvious example is the SICI -- an identifier for a particular article in a serial. Making these all resolvable in a useful way is a VERY non-trivial exersize. It is not at all easy, and a solution is definitely not cheap (DOI is an attempted solution; which some publishers choose not to pay for; both the DOI fees and the cost of building out their own infrastructure to support it). Why should we be prevented from using identifiers for a particular article in a serial until this difficult and expensive problem is solved?] So I don't buy that all identifiers must always be resolvable, and that if we can't make an identifier resolvable we can't use it. That excludes too much useful stuff. The next argument is, okay, so many all identifiers don't have to be resolvable, but even if it's not resolvable you can still use an http uri for it, just one that doesn't actually resolve. Formally, this is certainly correct. There's no formal requirement that an http URI go anywhere, that there even be an HTTP server responding at the hostname mentioned _at all_. So you _could_ use an http uri like that. But it gets confusing quickly, in part because the first argument referenced is still going on, and some people assume that any http URI _ought_ to be resolvable (to _something_; to _what_ is another argument). Using a non-http uri is a way to avoid confusion over your intentions, stating that you acknolwedged from the start that it was infeasible at the present time to provide http resolution for these identifiers. Jonathan Houghton,Andrew wrote: From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Monday, March 30, 2009 12:16 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? Some hints of the existing argument in other forums can be found in this post by Stu Weibel, and the other posts it links to. http://weibel-lines.typepad.com/weibelines/2006/08/uncoupling_iden.html Unfortunately, Stu is an author of the info URI specification and the he makes the same arguments that they made for the justification of the info URI RFC which has been debunked by the W3C: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50 Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Andy.
Re: [CODE4LIB] registering info: uris?
On Mar 30, 2009, at 11:18 AM, Ray Denenberg, Library of Congress wrote: From: Ross Singer rossfsin...@gmail.com nobody gives a damn about info:uris outside of libraries, Nor do people outside of libraries care about identifiers. You might be surprised: http://www.lsrn.org/ -hilmar -- === : Hilmar Lapp -:- Durham, NC -:- hlapp at duke dot edu : ===
Re: [CODE4LIB] registering info: uris?
At Mon, 30 Mar 2009 13:58:04 -0400, Jonathan Rochkind wrote: It's interesting that there are at least three, if not four, viewpoints being represented in this conversation. The first argument is over whether all identifiers should be resolvable or not. While I respect the argument that it's _useful_ to have resolvable (to something) identifiers , I think it's an unneccesary limitation to say that all identifiers _must_ be resolvable. There are cases where it is infeasible on a business level to support resolvability. It may be for as simple a reason as that the body who actually maintains the identifiers is not interested in providing such at present. You can argue that they _ought_ to be, but back in the real world, should that stand as a barrier to anyone else using URI identifiers based on that particular identifier system? Wouldn't it be better if it didn't have to be? [ Another obvious example is the SICI -- an identifier for a particular article in a serial. Making these all resolvable in a useful way is a VERY non-trivial exersize. It is not at all easy, and a solution is definitely not cheap (DOI is an attempted solution; which some publishers choose not to pay for; both the DOI fees and the cost of building out their own infrastructure to support it). Why should we be prevented from using identifiers for a particular article in a serial until this difficult and expensive problem is solved?] So I don't buy that all identifiers must always be resolvable, and that if we can't make an identifier resolvable we can't use it. That excludes too much useful stuff. I don’t actually think that there is anybody who is arguing that all identifiers must be resolvable. There are people who argue that there are identifiers which must NOT be resolvable; at least in their basic form. (see Stuart Weibel [1]). […] best, Erik 1. http://weibel-lines.typepad.com/weibelines/2006/08/uncoupling_iden.html ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgpuKdGTC0Mj7.pgp Description: PGP signature
Re: [CODE4LIB] registering info: uris?
From: Hilmar Lapp hl...@duke.edu Nor do people outside of libraries care about identifiers. You might be surprised: http://www.lsrn.org/ yes, I overstated, let me rephrase. There are communities who are interested in specific object classes and want identifier schemes for them. For libraries there are books, article, journals, and many others. And certainly this isn't limited to libraries, for example many scientific disciplines have a similar interest in identifer schemes for objects in specific object classes. But the term identifier has taken on a whole new meaning with the web. It has now been generalized to identify any resouce, and we don't even have a clear definition of resource, aside from the convoluted anything that can be identified - The discussions on this are often a convoluted mess, and it's no wonder location and identity get confused. And because of all the emphasis on solving this part of the web architecture - which haven't been accomplished, and there is debate within the W3C whether it is even possible - the original concept of identifer seems to be lost, aside from within the communities I alluded to above. And it is for those communities that the info URI is useful. Now as to my reference to religious issues, a statement like Having unresolvable URIs is anti-Web would be better to stated as: Having unresolvable URIs IN MY OPINION is anti-Web. It is an opinion, not a fact. Stating is as fact is dogmatic. It is a reasonable opinion, however, my opinion: Having unresolvable URIs IN MY OPINION is PRO-Web is just as reasonable. I needn't go into further detail, we've beaten this to death already. --Ray
Re: [CODE4LIB] registering info: uris?
Erik Hetzner wrote: I don’t actually think that there is anybody who is arguing that all identifiers must be resolvable. There are people who argue that there are identifiers which must NOT be resolvable; at least in their basic form. (see Stuart Weibel [1]). There are indeed people arguing that, Erik, on this very list. Like, in the email I responded to (did you read that one?). That's why I wrote what I did, man! You know I'm the one who cited Stu's argument first on this list! I am aware of his arguments. I am aware of people arguing various things on this issue. But when did someone suggest that all identifiers must be resolvable? When Andrew argued that: Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Okay, I guess he didn't actually SAY that you should never have non-resolvable identifiers, but he rather strongly implied it, by using the anti-Web epithet. But now we're arguing about what we're arguing about, which is the sure sign that an internet argument should die. Suffice it to say that there are at LEAST three viewpoints (if not more) being expressed in this argument, it's not just two sides. And that, I agree with Ray, these are NOT entirely solved questions, the right answer is not always obvious, reasonable people can disagree. (I happen to think there are a handful of clear WRONG answers, but also a variety of competing potentially right ones.) Jonathan
Re: [CODE4LIB] registering info: uris?
From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Monday, March 30, 2009 3:52 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? But when did someone suggest that all identifiers must be resolvable? When Andrew argued that: Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Okay, I guess he didn't actually SAY that you should never have non- resolvable identifiers, but he rather strongly implied it, by using the anti-Web epithet. You are correct that I didn't say that you should never have unresolvable identifiers and I wasn't implying that either. Though I was pointing out that sticking a href=info:lccn/sh2009123456Text/a into the hypertext system where info URIs are unresolvable negates the effect of linking to it in the first place. Andy.
Re: [CODE4LIB] registering info: uris?
There are obviously other uses for URIs than sticking them in an 'href' attribute of an a. Like, the uses I thought this conversation was about? What are we talking about again? Houghton,Andrew wrote: From: Code for Libraries [mailto:code4...@listserv.nd.edu] On Behalf Of Jonathan Rochkind Sent: Monday, March 30, 2009 3:52 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] registering info: uris? But when did someone suggest that all identifiers must be resolvable? When Andrew argued that: Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Okay, I guess he didn't actually SAY that you should never have non- resolvable identifiers, but he rather strongly implied it, by using the anti-Web epithet. You are correct that I didn't say that you should never have unresolvable identifiers and I wasn't implying that either. Though I was pointing out that sticking a href=info:lccn/sh2009123456Text/a into the hypertext system where info URIs are unresolvable negates the effect of linking to it in the first place. Andy.
Re: [CODE4LIB] Notes from Tuesday's Plone/Zope breakout session, C4L 2009 c4l09
Genny, I'm not really sure either--I was just the scribe for that session! The main difference I see is that clicking into a Plone website (when logged in) changes to edit mode. Sorry to not have a better answer. -Jodi On Mar 9, 2009, at 7:35 PM, Genny Engel wrote: I have heard this before, that Plone is better than Drupal for the end user / content contributor, and that people like the inline editing. I've been a little baffled comparing Drupal 6 and Plone because the editing features actually look about equally ... er ... not-quite-what-they're-gonna-want for our potential content contributors. I'm not really getting what's more inline about Plone editing -- both have an Edit option that brings up a web form. Perhaps the divide between Drupal and Plone editing interfaces was significantly greater in earlier Drupal versions? The only one I've really looked at in depth has been 6. Genny Engel Sonoma County Library gen...@sonoma.lib.ca.us 707 545-0831 x581 www.sonomalibrary.org schneide...@appstate.edu 03/09/09 11:00AM from Vignette ($ license, complicated end-user interface). Didn't have SDK's, hard to get content contributed. Content contributor user interface (Drupal easier for programmers, sucks for end-user.)
[CODE4LIB] plone4lib: Plone in libraries
Greetings! We're writing to invite you to get involved with plone4lib. We're a small online community using the open-source Plone content management system in libraries. Please visit http://plone4lib.org to read about how libraries around the world are using Plone, or add your own Plone-based library site. You can also join the plone4lib listserv: http://lists.plone.org/mailman/listinfo/plone4lib Inspired by a code4lib09 breakout session, and in the model of the drupal4lib community, we seek to share information and ideas about using Plone in libraries. We're inviting anyone using or interested in using Plone in libraries to join the site and contribute content: -Add your Plone-based library site to the World map -Share your Success Story -Introduce yourself on the mailing list, ask questions, and share ideas We're also looking for someone to design a banner for the site :-) Full credit, etc will be given on the site and in the News section so give it a shot :) Hope you'll join us! Darci Hanning, darci.hann...@gmail.com Jodi Schneider, jschnei...@pobox.com
Re: [CODE4LIB] registering info: uris?
At Mon, 30 Mar 2009 15:52:10 -0400, Jonathan Rochkind wrote: Erik Hetzner wrote: I don’t actually think that there is anybody who is arguing that all identifiers must be resolvable. There are people who argue that there are identifiers which must NOT be resolvable; at least in their basic form. (see Stuart Weibel [1]). There are indeed people arguing that, Erik, on this very list. Like, in the email I responded to (did you read that one?). That's why I wrote what I did, man! You know I'm the one who cited Stu's argument first on this list! I am aware of his arguments. I am aware of people arguing various things on this issue. My apologies for missing Andrew’s argument and not pointing out that you had originally pointed to Stuart’s argument. But when did someone suggest that all identifiers must be resolvable? When Andrew argued that: Having unresolvable URIs is anti-Web since the Web is a hypertext system where links are required to make it useful. Exposing unresolvable links in content on the Web doesn't make the Web more useful. Okay, I guess he didn't actually SAY that you should never have non-resolvable identifiers, but he rather strongly implied it, by using the anti-Web epithet. Given Andrew’s later response, I would like to restate my previous argument: I don’t [] think that there is anybody who is +seriously+ arguing that all identifiers must be resolvable +to be useful as identifiers+. best, Erik ;; Erik Hetzner, California Digital Library ;; gnupg key id: 1024D/01DB07E3 pgps01lTF1mj0.pgp Description: PGP signature
