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

Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

From: Hugh Glaser <hg@ecs.soton.ac.uk>
Date: Fri, 5 Nov 2010 17:11:39 +0000
To: "nathan@webr3.org" <nathan@webr3.org>, Mischa Tuffield <mmt04r@ecs.soton.ac.uk>
CC: Norman Gray <norman@astro.gla.ac.uk>, Linked Data community <public-lod@w3.org>
Message-ID: <EMEW3|7242a5c7b6c3ca97b20eb8f7e695ed90mA4HC602hg|ecs.soton.ac.uk|C8F9E98C.11307%hg@ecs.soton.ac.uk>
Seems a good point to ask for some help my understanding.
I would guess I am about to display great ignorance here, but... :-)
My understanding of <http://example.com/about#alice> is that the
sub-application libraries (woolly terms, to include caches, etc.!) will
(must) fetch <http://example.com/about> as a page, and then do something
about the alice frag.
Later, if I ask for <http://example.com/about#bob>, and expiry etc. was
not set aggressively, then there is a distinct possibility that the page
will not be re-fetched, but just hand back the "version: of
<http://example.com/about> that the server chose to return in response to
the <http://example.com/about#alice> request.
So if I have loads of frags in <http://example.com/about>, then if I don't
give them all every time, the consuming app can legitimately find that the
others, such as <http://example.com/about#bob> are not there?
Sorry if this is a question that everyone already knows the answer to.

On 05/11/2010 16:42, "Nathan" <nathan@webr3.org> wrote:

>Mischa Tuffield wrote:
>> On 5 Nov 2010, at 15:07, 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.
>>> 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
>> Indeed, I think I eluded to this in my email to the "303" thread. The
>>idea is to have smaller more manageable RDF documents on the web, IMHO
>>targeted documents are more interesting than ones which talk about a
>>million and one things. Again, I will try and draw an analogy here; at
>>is stands, sites like the BBC, have one document per story, there is
>>nothing stopping the BBC from having one page will all of its content on
>>it, i.e. with each article having its own #fragment, but it is a lot
>>neater to have a document per story.
>I don't follow why it's inferred here that if you use a fragment then
>all information must be in one document?? makes no sense. You can use
>exactly the same one article per document approach with frags.
Received on Friday, 5 November 2010 17:13:33 UTC

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