Re: URI Fragments

[joel sachs]

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