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
>>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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:09:46 UTC