W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

From: Nathan <nathan@webr3.org>
Date: Fri, 05 Nov 2010 16:36:17 +0000
Message-ID: <4CD43281.50507@webr3.org>
To: Norman Gray <norman@astro.gla.ac.uk>
CC: Linked Data community <public-lod@w3.org>, Richard Cyganiak <richard@cyganiak.de>
Norman Gray wrote:
> Nathan, hello.
> On 2010 Nov 5, at 14:31, Nathan wrote:
>> No, using hash URIs would certainly not mean that at all!!
>> Use the URI pattern you wanted to use and stick #i or something at the end of each one. Hash URIs *do not* mean you put everything in one document, it simply means that you have one identifier for the doc and one for each thing described within it, whether you put 1, 10 or 100 things in the doc.
> OoooK -- I see.  Thanks for that clarification.
> When I see "the hash-URI pattern", I think of the pattern described in <http://www.w3.org/TR/cooluris/#hashuri>, which (as I understand it) is what I was effectively describing.  There, <http://example.com/about#alice> is the name for alice, and that is described along with a lot of other objects in the IR <http://example.com/about>.  As the authors there discuss it, this is better for 'small' sets of names, whereas "the slash URI pattern" as described there is better for larger ones.

Whoops, if that's what COOL is inferring then that's probably a bug 
which needs addressed, Richard can you clarify / let us know if it's 
possible to do anything with COOL (maybe even update and republish?)

> The pattern you're describing (I don't know -- a hash-slash-URI?, which has one IR per NIR) has a distinct sets of tradeoffs, I think, but has the particular advantage that, if every NIR has a hash in it, then the IR/NIR distinction can be maintained without any status code gymnastics.

Well, the pattern I'm describing is whatever you want it to be - pick a 
URI pattern that suits you and doesn't have the trade offs, just use 
/slash for docs and #frags for things. You can put the description of 3 
things in one doc, or one doc per thing, or whatever suits logically to 
be both HTTP friendly, provide a full description of that which you are 
describing, and with suitable granularity that you can't for see 
document size becoming an issue.

However, even if document size ever does become an issue (because the 
description of the thing or things is too big) then you can use the 
link:listDocumentProperty approach as described in the Linked Data 
Design Issue [1] to factor properties of a certain type in to a 
different doc.

[1] http://www.w3.org/DesignIssues/LinkedData.html


Received on Friday, 5 November 2010 16:37:31 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC