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

Re: [WNET] new proposal WN URIs and related issues

From: Mark van Assem <mark@cs.vu.nl>
Date: Wed, 19 Apr 2006 14:50:27 +0300
Message-ID: <44462403.6050609@cs.vu.nl>
To: Jan Wielemaker <wielemak@science.uva.nl>
CC: SWBPD list <public-swbp-wg@w3.org>, "Ralph R. Swick" <swick@w3.org>, Guus Schreiber <guus@few.vu.nl>


Hi Jan,

> I'm in favour of one namespace. It is after all one `document' and as
> all resources are controlled by one entity (you :-) you can avoid

Yes, it would be easier to manage :-)

> Whats a CBD? Its not mentioned in [2]. Finally you gave the motivation

It is explained and referenced in [1]. Basically it's the set of triples 
that has one particular resource as its subject. It has been proposed as 
a suitable 'default response' to the question 'tell me about this 
resource'. We would like to return a CBD on an HTTP GET for a WN URI.

> for the / :-) Anyway, using / is still wrong. Not sure how, but this

I'm not sure what you think the motivation was... Actually thinking back 
I think the motivation was twofold

1) esthetics
2) easy way to define URIs that refer to larger chunks, e.g.
  http://wordnet.princeton.edu/wn20/wordsense/bank could refer to all 
the wordsenses containing 'bank'. I moved this idea to the 'Issues' 
section of [1].

> problem must be solved otherwise. Of course, unless you propose to revise
> XML/RDF and preferably also XML namespace handling :-)

I think especially that only allowing QNames for attributes in RDF/XML 
is pretty strange. You can't even replace <rdf:type ...> for its 
expanded URI. Probably other notations do not have this quirk?

Thanks again for all your offline explanations, you finally got through 
to me :-)

Mark.

[1]http://www.w3.org/2001/sw/BestPractices/WNET/wn-conversion
[2]http://www.w3.org/TR/swbp-vocab-pub/
[3]http://www.w3.org/2001/sw/BestPractices/WNET/wn-conversion-20060202
[4]http://lists.w3.org/Archives/Public/public-swbp-wg/2006Feb/0087
Received on Wednesday, 19 April 2006 11:51:25 UTC

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