I am still musing over Thomas Neidhart’s comment:
To understand this identifier you would need implicit knowledge about the structure and nature of every possible identifier system in existence, and then you still do not know who has more information about it.
Aside from questions of universal identifier systems failing without exception in the past, which makes one wonder why this system should succeed, there are other questions.
Such as why would any system need to encounter every possible identifier system in existence?
That is the LOD effort has setup a strawman (apologies for the sexism) that it then proceeds to blow down.
If a subject has multiple identifiers in a set and my system recognizes only one out of three, what harm has come of the subject having the other two identifiers?
There is no processing overhead since by admission the system does not recognize the other identifier so it doesn’t process them.
The advantage being that some other system make recognize the subject on the basis of the other identifiers.
This post is a good example of that practice.
I had a category “Linked Data,” but I added a category this morning, “LOD,” just in case people search for it that way.
Why shouldn’t our computers adapt to how we use identifiers (multiple ones for the same subjects) rather than our attempting (and failing) to adapt to universal identifiers to make it easy for our computers?
In my comment I wanted to illustrate that using non-URI identifiers in the context of LOD does not make much sense (at least as long you do not have an intermediate resolution service, but I do not know if this makes sense either).
@Ambiguity: there is ambiguity and we have to accept this and design solutions around it. In the 80s there were a lot of efforts to build expert systems which tried to incorporate all knowledge and reasoning into one system and it seems today that this approach has failed.
Imho, a data provider in the LOD context does not have to resolve the issue of ambiguity by himself, it is the task of the one aggregating knowledge to do so. Though, the data provider needs to provide the capabilities to do an ambiguity resolution based on the context.
To be more concrete: If you want to aggregate data from different data providers and you are not sure whether you refer to the right subject, you have to analyze the properties of the subject and decide whether its appropriate for you.
Comment by Thomas Neidhart — November 19, 2010 @ 8:54 am
Thomas,
It seems we have come full circle back to my post LOD, Semantic Ambiguity and Topic Maps.
All I have been saying is that reliable aggregation depends upon knowing enough to distinguish subjects of interest.
Note the word reliable. It is of little use if I aggregate data that cannot then be usefully aggregated again, perhaps differently, by the next user of the data.
Or is that the business model?
Putting up data on a “your guess is as good as mine” basis in hopes of attracting users who need sensibly aggregated data?
But when the result is delivered, it is very difficult for them to aggregate that data with other data they or others have. (Because they don’t know on what basis the data was originally aggregated.)
That sounds like a very sad business model.
Not one I would accept as an informed customer.
Comment by Patrick Durusau — November 19, 2010 @ 3:51 pm