RE: Identity of URIRefs / Resources

Hans,

> I looked at < <http://taguri.org> http://taguri.org> and found your example:
> tag:hawke.org,2001-06-05:Taiko
> 
> May I ask for an example RDF/XML code snippet showing how you would use such
> tags?

Heh, it is a good example, but not mine!  I have nothing to do with the tag URI
scheme.  :-)

An example of my almost current thinking can be found at [1]; although, not
everyone in the research lab where I work agree with those findings yet (and
they are not yet complete).

I like the tag scheme since it guarantees that you never step on some else's
toes when assigning URI references.  Cool URIs don't change [2], so once you
mint a URI it is effective gone from the space of available URI references to
assign to other resources.

You can't guarantee URI persistence [3] unless you own the domain name for DNS
based schemes [4] and even then it is hard.  So you need space _and time_
information to avoid possible collisions [5] when you don't own the domain any
more [6].  The tag scheme enforces this pattern - the http scheme does not - so
it is safer to use tag URI strings.

Sandro Hawke's email is also insightful from the POV of effectivness rather
than avoiding collisions.

> From a data modelling point of view it's not a very good method, because if
> the relationship between you and Taiko would no longer exist (e.g. you sell
> him) then Taiko would need another tag. That is not very helpful in case you
> want to gather the lifecycle information about Taiko.

That is true, but you have the same situation even if you use http.

> I can see why you came
> up with this solution, because it is a matter of descriptive identification,
> i.e. an identification by means of one or more properties. Filling out a form
> for entering the USA does the same: name, first name, date of birth, place of
> birth, nationality, gender, etc, until one can be reasonably certain that
> there is only one person that fits the pattern.

Sort of.  The tag scheme makes it easier to avoid collisions since it
decentralizes the authority of a URI in predictable ways - namely, person X
gets to say what URIs mean when prefixed with tag (always) specifying a time
and place.  It is still possible to collide, but the onus is on a smaller
number of people.

> But that is besides the point, because my question to you is: what is wrong
> with a fragment identifier described, amongst others, in the RDF Primer? So
> something like  <http://www.hawke.org/index.html#Taiko-2005-06-05>
> http://www.hawke.org/index.html#Taiko-2005-06-05? What are the advantages of
> using your tagging method over that of using fragment identifiers? Or am I
> missing something?

URIs minted with the tag URI scheme can still have fragment identifiers, can
they not?

I like using paths (using the pattern of the Dublin Core [7]) for resources
that are minted only in the context of another resource (like the session of a
user [8]).  I.E. usually instances.  I like using fragments for parts of a
resource.  I.E. classes in an Ontology.  But this is more of a personal opinion
I think.

--
Jimmy Cerra

[1]
http://ummo.blogspot.com/2005/06/request-for-comments-uri-naming.html#uri_guideline_example
[2] http://www.w3.org/Provider/Style/URI.html
[3] http://www.w3.org/TR/webarch/#def-URI-persistence
[4] http://www.w3.org/2001/tag/doc/metaDataInURI-31.html#id2607921
[5] http://www.w3.org/TR/webarch/#def-uri-collision
[6] http://bobwyman.pubsub.com/main/2005/03/tag_uri_scheme_.html
[7] http://dublincore.org/documents/dcmes-xml/
[8] http://ummo.blogspot.com/2005/06/request-for-comments-uri-naming.html#uri_guideline_example


		
__________________________________ 
Discover Yahoo! 
Stay in touch with email, IM, photo sharing and more. Check it out! 
http://discover.yahoo.com/stayintouch.html

Received on Sunday, 5 June 2005 18:49:21 UTC