Re: URI Fragments

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

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

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 16:24:50 UTC