W3C home > Mailing lists > Public > public-swbp-wg@w3.org > March 2006

Re: WNet review

From: Mark van Assem <mark@cs.vu.nl>
Date: Wed, 01 Mar 2006 14:24:22 +0100
Message-ID: <4405A086.3010000@cs.vu.nl>
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
> 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.


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?


  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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:31:18 UTC