Re: isDefinedBy and isDescribedBy, Tale of two missing predicates

Hugh, 

On 5 Nov 2010, at 17:11, Hugh Glaser wrote:

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

Am not what you mean by "if I don't give them all every time" here. 

But FWIW if you curl http://example.com/foo#bar

or curl http://example.com/foo#foobar

you will get back the same document http://example.com/foo

Mischa

> 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
>> 
> 
>