- From: Mark van Assem <mark@cs.vu.nl>
- Date: Wed, 01 Mar 2006 14:24:22 +0100
- To: Kjetil Kjernsmo <kjetilk@opera.com>
- CC: SWBPD list <public-swbp-wg@w3.org>
Hi Kjetill, >>I personally feel that the currently proposed scheme is more clear >>because it typographically separates the "local ID" from the >>"namespace" part of the URI, which helps humans to read the URIs. Is >>this way of composing slash URIs considered counter-intuitive by most >>people? > > > Hmmm, I don't know. I think many have a intuitive "file system" image, > and would decompose the URI > http://wordnet.princeton.edu/wn/2.0/bank/noun#1 > to mean "the word senses of bank", "then just the nouns of bank" and the > "first noun sense". That's what I would do. Maybe I understood incorrectly, but the example you give is not the proposal in the draft, e.g. http://wordnet.princeton.edu/wn/bank-noun-1/ which actually has the same sequence of information, it only "chunks" the local part together. If other people also find this proposal counter-intuitive we can of course go for your proposal (but without the hashes I would say). > However, your argument in the document is that: "The disadvantage of > hash URIs is that when a HTTP GET is done [...] the browser will return > the whole document", which is a valid argument for not returning the > whole wordnet database on that GET. It is not, however, a complete > argument against returning a set of senses. Ok, next version will contain a more elaborate answer (including the argument in my last mail). Hope that's ok? > I'm much more inclined to focus on returning a "reasonable chunk" for > any HTTP GET. Unintended retrievals of the whole WN db should be > avoided, but a single WordSense seems like an unreasonable small chunk > to me. You're saying that an advantage of your slash URI format is that there are more bindings to differently-sized chunks of WordNet, e.g. a URI for all bank-wordsenses? In effect you'd be making possible more GETs that return the same RDF as a SPARQL query (as opposed to when the current URI proposal is used, where you can only retrieve single WordSenses, not sets of WordSenses)? Why would returning a single WordSense (its CBD) be unreasonable small? > would require a (SPARQL) query, I don't think agents should infer what > will be returned based on the URI itself. I completely agree, but that doesn't mean we can't create URIs that are meaningful to humans, helping them to parse data or write GETs. Or do I misunderstand you here? Regards, Mark. -- Mark F.J. van Assem - Vrije Universiteit Amsterdam markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Wednesday, 1 March 2006 13:25:14 UTC