Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

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.
Cheers
Hugh

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
>>>gymnastics.
>> 
>> 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.
>
>Best,
>
>Nathan
>

Received on Friday, 5 November 2010 17:13:33 UTC