Re: URI Fragments

joel sachs wrote:
> 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?")

noted; we can agree though that if you remove the representation then
the fragment identified resource can no longer be dereferenced yes?

whereas if you use a non-fragment uri to identify a resource and 303 it
through to it's representation; then you are free to have multiple
mediatypes and move the representation without loosing the dereferencing
capability.

or am I wrong here?

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

yes which is why I said:

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

regards!

Received on Friday, 12 March 2010 19:08:41 UTC