If I read Halpin and others correctly, URIs identify the subjects they identify, except when they identify some other subject and it isn’t possible to know which of any number of subjects is being identified.
That is what I (and others) take as “ambiguity.”
Some readers have taken my comments to on URIs to be critical of RDF, which wasn’t my intent.
What I object to is the sentiment that everyone should use only URIs and then cherry pick any RDF graph that may result for identity purposes.
For example, in a family tree, there may be an entry: John Smith.
For which we can create: http://myfamilytree.smith.com/john_smith
That may resolve to an RDF graph but what properties in that graph identify a particular John Smith?
A “uniform” syntax for that “identifier” isn’t helpful if we all reach various conclusions about what properties in the graph to use for identification.
Or if we have different tests to evaluate the values of those properties.
Even with an RDF graph and rules for which properties to evaluate, we may still have ambiguity.
But rules for evaluation of RDF graphs for identity lessen the ambiguity.
All within the context, format, data model of RDF.
It does detract from URIs as identifiers but URIs as identifiers are no more viable than any single token as an identifier.
Sets of key/value pairs, which are made up of tokens, have the potential to lessen ambiguity, but not banish it.
Patrick,
I agree with you. But, IMHO, the problem does not lie in using URIs as subject identifiers, but in *reusing* them, as with any other reuse of identifiers. It is the global and public connotation of the URI concept that is dangerous, in particular if you anarchically aggregate new data and publish it. With each reuse of an identifier, you devalue the identifier, since the re-user might misinterpret and attach statements to the wrong subject.
I like the approach the TMRM takes very much: it does not let you use your own identifiers, it *forces* you to. On the basis of the TMDM and other URI based integration technologies, it is still possible to emulate these late merging properties with the separation of content (one authentic identifier per subject and statements about it) and glue documents (subject identity statements only). The issue at hand is not computational, logical or mathematical. It is a semiotical one: What is signified? It is also a philosophical one: How is communication possible? In this aspect I like Luc Steel’s work:
http://www.topincs.com/people/robertcerny/1036
http://www.topincs.com/people/robertcerny/758
Comment by Robert Cerny — November 20, 2010 @ 11:38 am
Robert,
I am not sure it is “reuse” of an identifier as much as any single identifier being subject to varying interpretation that gives rise to ambiguity.
That is to say I could have a URI that is denoted as a subject identifier and that resolves to five key/value pairs (in any syntax or data model) that has greater likelihood of ambiguity than a subject identifier that resolves to ten key/value pairs.
Everyone should not rush out and have some # of key/value pairs to identify their subjects.
Depends on your circumstances. In the US, for some purposes, the Social Security Administration relies upon 9-digit social security numbers as unique identifiers. But not for all purposes.
What identifier you need and how much ambiguity will result is entirely dependent upon the circumstances.
URIs were a syntactic answer to a semiotic question.
Interesting video’s with Steel. I don’t think the first example was a failed language game. Where the robots gave different answers. Had they declared war at that point I would say they were almost human. 😉
PS: Seriously, thanks for the pointers! I haven’t followed that sort of work and it is good to have a starting place.
Comment by Patrick Durusau — November 20, 2010 @ 1:31 pm
[…] This post was mentioned on Twitter by Robert Cerny, Patrick Durusau. Patrick Durusau said: URIs and Identity, http://tm.durusau.net/?p=4192 […]
Pingback by Tweets that mention URIs and Identity « Another Word For It -- Topsy.com — November 20, 2010 @ 2:39 pm