Re: URI Fragments

Nathan,
A couple of points ...

On Fri, 12 Mar 2010, Nathan wrote:

> joel sachs wrote:
>> Nathan,
>>
>> I'm not sure it's correct to refer to your examples as "primary" and
>> "secondary" resources. As you point out, it is not true that
>>
>>> if I remove http://www.w3.org/People/Berners-Lee/card then
>>> http://www.w3.org/People/Berners-Lee/card#i no longer exists.
>>
>> since the first URI refers to an information resource, while the second
>> refers to a non-information resource.
>
> with regards primary and secondary:
>
> http://www.ietf.org/rfc/rfc3986.txt states:
>
>   The fragment identifier component of a URI allows indirect
>   identification of a secondary resource by reference to a primary
>   resource and additional identifying information.  The identified
>   secondary resource may be some portion or subset of the primary
>   resource, some view on representations of the primary resource, or
>   some other resource defined or described by those representations.
>
> http://www.w3.org/TR/webarch/#fragid states:
>
>   The fragment identifier component of a URI allows indirect
>   identification of a secondary resource by reference to a primary
>   resource and additional identifying information
>
> hence the usage :)
>

But http://www.w3.org/TR/webarch/#fragid stresses that the terms "primary" 
and "secondary" apply only in the context of a particular URI; 
they do not imply any sort of "you must have the first to have the 
second" significance. This is in contrast to "database tables" and 
"database rows", or "London" and the "Tower of London". So lessons that 
you draw from resources that are "primary" and "secondary" in an ontological sense do 
not apply to the resources in a fragment URI. (I'm referring here to your 
last sentence of this email, which states that
"if I delete a Primary resource, the
secondary resources must also be deleted", and this stands true in 99%
of use-cases; would that not indicate that the use-case where it doesn't
appear like it should be true may be implemented incorrectly?")

>> You seem to take this as an argument against fragment identifiers, but
>> it doesn't just apply to hash URIs. If the server www.w3.org goes down,
>> then all URIs that it dereferences become non-dereferenceable, whether
>> they are hash URIs or slash URIs.
>
> I hope this doesn't come across wrong, but if we're saying that one
> server can go down, then all servers can go down; and all linked data
> can no longer be dereferenced;

Surely the Web of Data should have a little bit of fault tolerance?

> so for the sake of this conversation and
> the whole linked data thing in general I'm most interested in addressing
> what to do whilst the servers are live.

What I'm getting at is that eliminating fragment URIs doesn't eliminate 
the problem you bring up, which is that a URI can be rendered 
dereferenceable after it's already in use, either by deleting the page 
that it dereferences to (your example) or by killing the server that 
dereferences it (my example). My point is that mechanisms should exist to 
deal with this.

Regards -
Joel.

>
> As for an argument against fragment identifiers - I'm not against them;
> however if we take the case of TimBL's card; personally I can't see any
> reason why he couldn't have a personal uri of say
> http://www.w3.org/TimBL which 303 See Other through to his card; then
> his personal uri is a resource all of its own and independent of any
> representation; thus allowing representations to be moved around /
> deleted without any effect on his personal URI, and further allow for
> multiple information resources describing him, with different
> media-types. This is digressing though and probably not worth discussing.
>
>> Now, must we stop using a URI when the server that dereferences it goes
>> down? I think there are cases where the answer is no, where it makes
>> sense to continue using the URI as an identifier, even if the URI is no
>> longer valid as an address. In the above case, there are
>> many webpages making assertions about
>> http://www.w3.org/People/Berners-Lee/card#i ,
>> and those assertions are valid, regardless of the existence of
>> the server www.w3.org. Making thoses assertions easy to find might be a
>> challenge, of course, which is why I would like to see rdf browsers do
>> more than simply issue a GET on a URI when trying to resolve it.
>
> Unsure, and I think about these things often; all I will say is that it
> appears the web of data is fault tolerant thanks in part to sameAs and
> dcterms:replaces - personally I would like to see usage of 410 Gone and
> 301 Moved Permanently to help matters but that's a different (yet
> related) topic.

> Back to the point in hand, surely "if I delete a Primary resource, the
> secondary resources must also be deleted", and this stands true in 99%
> of use-cases; would that not indicate that the use-case where it doesn't
> appear like it should be true may be implemented incorrectly? especially
> if that same use-case can be implemented in a different way and allow
> this statement to be true 100% of the time.
>
> (trying to tread cautiously here)!
>
> regards, nathan
>
>>
>> On Fri, 12 Mar 2010, Nathan wrote:
>>
>>> Hi Again :)
>>>
>>> Last question(s) related to fragments.. if I have:
>>>  http://example.org/something
>>>  http://example.org/something#a
>>>
>>> Those are two unique URIs and thus two unique resources (?)
>>>
>>> And the semantics of a fragment means that
>>> http://example.org/something#a is a secondary resource, where
>>> http://example.org/something is the primary resource (?)
>>>
>>> Then if I delete a Primary resource, the secondary resources must also
>>> be deleted, true / false (?).
>>>
>>> Here are some examples, which may seem like over kill but some are
>>> interesting and generally I *feel* rules like this should be either
>>> always true, or always false, never varying.
>>>
>>> examples:
>>> if I remove a database table, then all it's rows also no longer exist.
>>> if I remove London then the Tower of London also no longer exists.
>>> if somebody removes me, then my arms also no longer exist.
>>> if I remove test.html then test.html#whatever no longer exists.
>>> if I remove test.rdf then test.rdf#this no longer exists
>>> if I remove http://www.w3.org/People/Berners-Lee/card then
>>> http://www.w3.org/People/Berners-Lee/card#i no longer exists.
>>>
>>> conversely:
>>> if I remove a row, the table still exists
>>> if I remove the Tower of London, London still exists
>>> if you remove my arms, I still exists and I'll find another way to type.
>>> if I remove test.html#whatever test.html still exists
>>> if I remove test.rdf#this, test.rdf still exists
>>> if I remove http://www.w3.org/People/Berners-Lee/card#i then
>>> http://www.w3.org/People/Berners-Lee/card still exists.
>>>
>>> If the above is true (secondary resource must also be deleted on removal
>>> of primary resource), then I should never use a fragment Identifier to
>>> refer to a non-virtual object (i.e. "me" a Person) - because I can't be
>>> deleted by simply removing a resource. (?)
>>>
>>> Regards!
>>>
>>> Nathan
>>>
>>
>>
>
>

Received on Friday, 12 March 2010 17:52:24 UTC