W3C home > Mailing lists > Public > public-lod@w3.org > March 2010

Re: URI Fragments (typo fixed version)

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Fri, 12 Mar 2010 12:53:06 -0500
Message-ID: <4B9A7F82.8040607@openlinksw.com>
To: nathan@webr3.org
CC: Linked Data community <public-lod@w3.org>
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 (?)
>   

My world view (i.e. I don't do Resource and Information Resource lingo):

Careless and dangerous, but accurate.

1. http://example.org/something  -- a resource URI
2. http://example.org/something#a -- a resource URI


Less confusing, assuming you are have a # terminated URI pattern in play:

1. http://example.org/something  -- a resource URL
2. http://example.org/something#a -- a data object URI (if we are 
talking about a commonly used Linked Data pattern, then URL above would 
be conduit to the EAV model based representation of the description of 
this data object)



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

Sorta.
 
> Then if I delete a Primary resource, the secondary resources must also
> be deleted, true / false (?).
>   
Not necessarily, this really depends on the Linked Data pattern you've 
adopted re. generic HTTP URIs. Basically, the pattern you've adopted 
such that: you can Reference a Data Object and Access a Representation 
of its Description, via a single Generic HTTP URI.

> 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.
>   
No, you've lost access to description of:  
<http://www.w3.org/People/Berners-Lee/card#i>, of course it still 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.
>   

How do you remove: <http://www.w3.org/People/Berners-Lee/card#i> ? Let's 
say you take it out of <http://www.w3.org/People/Berners-Lee/card>, then 
for agents that seek description of 
<http://www.w3.org/People/Berners-Lee/card#i> via aforementioned URL, 
you get nothing. Nothing stops the 
<http://www.w3.org/People/Berners-Lee/card#i> description existing in my 
linked data space :-)

> If the above is true (secondary resource must also be deleted on removal
> of primary resource),

Not true .

>  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. (?)
>   
Best to think about the issue of "Identifier" as absolutely distinct 
from "Representation".

Links:

1. 
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/clamen/OODBMS/Manifesto/htManifesto/node4.html 
-- might come in handy re. Identifier matters .



-- 

Regards,

Kingsley Idehen	      
President & CEO 
OpenLink Software     
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen 
Received on Friday, 12 March 2010 17:53:33 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:25 UTC