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

[WNET] URIs as primitive queries?

From: Mark van Assem <mark@cs.vu.nl>
Date: Mon, 27 Mar 2006 20:04:43 +0200
Message-ID: <4428293B.3000407@cs.vu.nl>
To: SWBPD list <public-swbp-wg@w3.org>


Hi all,

In a recent discussion I had with Kjetil [1] the option popped up of 
using URIs as a means of primitive queries. The following URI in 
WordNet refers to the first NounWordSense of the word "bank", which is 
an RDF node in WN:

    http://wordnet.princeton.edu/wn/wordsense/noun/bank/1/

(note that this format for WN URIs is a new proposal, not the current 
proposal in the WN draft [2])

The current proposal is to return the CBD [3] of the requested RDF node.

Kjetil argued that many agents would probably like somewhat bigger 
chunks of data at once, e.g. all NounWordSenses of "bank". This could 
be done by returning the set of NounWordSenses with the Word "bank" on 
HTTP GETs on the URI:

   http://wordnet.princeton.edu/wn/wordsense/noun/bank/

Of course this problem could also be solved with a full SPARQL service 
for WN, but it is yet unclear if we would have anything more than 
static files and server URI rewrites to our disposal. Then this might 
be a nice alternative - or even if we have SPARQL, just a nice 
intermediate choice.

However, this second (type of) URI does not refer to any RDF node or 
RDF arc. So I'm wondering whether this use of URIs is "accepted 
practice" (or could become such a thing) or "should be avoided at all 
costs" because the approach mixes the naming of nodes with naming sets 
of nodes.

Thanks for the advice,
Mark van Assem.

[1]http://lists.w3.org/Archives/Public/public-swbp-wg/2006Mar/0076.html
[2]http://www.w3.org/2001/sw/BestPractices/WNET/wn-conversion.html
[3]http://www.w3.org/2001/sw/BestPractices/WNET/wn-conversion.html#querying
-- 
  Mark F.J. van Assem - Vrije Universiteit Amsterdam
        markREMOVE@cs.vu.nl - http://www.cs.vu.nl/~mark
Received on Monday, 27 March 2006 18:04:54 UTC

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