- 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