A Guide to Publishing Linked Data Without Redirects is a proposal by Ian Davis to avoid the 303 while distinguishing between “things” and their descriptions.
A step in the right direction.
November 8, 2010
10 Comments
RSS feed for comments on this post.
Sorry, the comment form is closed at this time.
[…] Another Word For It Patrick Durusau on Topic Maps and Semantic Diversity « A Guide to Publishing Linked Data Without Redirects – Post […]
Pingback by Ambiguity and Linked Data URIs « Another Word For It — November 8, 2010 @ 6:14 am
Probably a step in the right direction but it does not solve the problem.
http://dbpedia.org/resource/John_Lennon returns 303. That’s good according to the guidelines. 303 indicates an abstract concept. “John Lennon” isn’t an addressable subject.
Given, I want to talk about the *address* http://dbpedia.org/resource/John_Lennon. How can I do that?
If the request returns 303 it is automatically treated as a non-addressable subject. If it returns 200 it’s an addressable subject. So what? Neither 303 nor 200 fixes the problem of non-addressable vs. addressable subjects.
BTW, TMRM seems to introduce the same problem.
proxyA = {
iri: ‘http://dbpedia.org/resource/John_Lennon’,
name: ‘John Lennon’
}
proxyB = {
iri: ‘http://dbpedia.org/resource/John_Lennon’,
name: ‘John Lennon’
}
One of the proxies refers to the person “John Lennon”, one proxy refers to the address specified by the “iri” property. Do you know which addresses the the person?
Would a legend help you to distinguish between both proxies?
Comment by Lars — November 8, 2010 @ 5:12 pm
The answer is obviously a different property (proxy) for ‘iri’, but isn’t this concept important enough to be a part of TMRM like “isa” and “sub”?
Comment by Lars — November 8, 2010 @ 5:39 pm
Gee, and I had such a good answer written out!
Well, let me ask you this question:
If the TMRM defines “isa,” “sub,” and “iri,” what other keys should it define?
What about “anyURI,” or “ancestor-or-self?”
The important concept is that legends define what they choose to mean by particular keys. Not the TMRM.
The problem with the TMRM making such choices is that they would automatically preclude the modeling by a legend of other legitimate choices.
It is entirely possible that someone could define IRI to never act as a locator (I know someone who has done that). But the other choice could be made as well, for equally valid reasons.
Which is why I hope in the nearly final draft of the TMRM due out later this month, “isa” and “sub” will appear in the path language annex. There are various forms of both and people should be able to define which one they want.
The editors of the TMRM (or at least me at any rate) have been negligent in not following up on the abstraction of the TMRM with either syntaxes for writing legends and at the same time illustrations of it means to write a legend.
Comment by Patrick Durusau — November 8, 2010 @ 6:03 pm
We both agree that “proxyA” and “proxyB” would merge acc. to TMRM and no legend can avoid that, right?
If we laugh (or smile at least) at RDF and their problems due to addressable and non-addressable subjects, shouldn’t Topic Maps give an answer? TMDM provides an answer. TMRM doesn’t. Do you agree?
Acc. to my understanding “isa” and “sub” are defined as abstract concepts and user may “define what you want” if you can fulfil certain constraints.
Why isn’t addressable vs. addressable a (abstract) concept in TMRM?
Comment by Lars — November 8, 2010 @ 6:25 pm
> Why isn’t addressable vs. addressable a (abstract) concept in TMRM?
I meant: Why isn’t addressable vs. non-addressable a (abstract) concept in TMRM?
Comment by Lars — November 8, 2010 @ 6:30 pm
“We both agree that “proxyA” and “proxyB” would merge acc. to TMRM and no legend can avoid that, right?”
No.
You are presuming string equivalence of the names of keys means they have the same criteria for merging. That is one test for merging. Here is another:
***
iri equivalence +
class = resource
If class = unknown, no merging.
***
“Why isn’t addressable vs. addressable a (abstract) concept in TMRM?”
The TMRM reserved it for legends to define addressable vs. non-addressable subjects. That is it did not answer on purpose. It is a feature, not a bug. 😉
Yes, addressable vs. non-addressable as an (abstract) concept looks quite important to us and it is a central defect of RDF, but that is simply one case.
Hmmm, once you start talking about URIs, a specific address space, then it is possible to intelligently discuss issues such as addressable and non-addressable. But where that distinction lies in practice depends on the addressing system.
For example, in the US, is a Social Security Number an address or an identifier? Really depends upon the context in which it is being used.
The point being that once we start defining subjects and their relationships to other subjects (inevitably follows), then we have simply invented yet another system for talking about subjects.
The TMRM is an attempt to provide an abstract framework within which you can look at two or more information systems, intelligently discuss the subject they do or don’t identify and how, then fashion legends that enable you to meaningfully combine those information systems. But those are always your legends and not the TMRM.
The TMRM gives us a rhetoric for discussion of the proxies that represent subjects, their properties and the rules that govern them. How we flesh out that rhetoric is up to us.
(isa and sub are defined more than as abstract concepts, they have defined properties)
(Apologies for the length. I need to write something much longer with examples but that is unlikely this month.)
Comment by Patrick Durusau — November 8, 2010 @ 7:37 pm
You’re right: Addressable vs. non-addressable subjects shouldn’t belong to TMRM. I ignored the fact that IRIs have no meaning in TMRM (that’s also a feature not a bug).
Regarding “isa” and “sub”: I disagree. They don’t have defined properties; they define a concept/a behaviour, though. TMRM does not define an “isa” or “sub” proxy; it simply states that proxies may have a type-instance/supertype-subtype relationship and the constraints of these relationships.
Comment by Lars — November 9, 2010 @ 3:58 am
The problem I see with “isa” and “ako” are the “constraints” of those relationships.
I say “ako” because we switch terminology between two paragraphs, saying subclass-superclass in one and then “ako” in the next. Need to fix that in any event.
But we say that “ako” is reflexive and transitive. True in some cases but not all.
Same for “isa” being non-reflexive and transitive.
It would be like defining a topic map for geometry and saying:
“Through a point not on a line, there is no more than one line parallel to the line.” (stolen from Euclidean and Non-Euclidean Geometry) for all geometries recorded in the topic map.
Which works, if you want to exclude all non-Euclidean geometries.
That’s the problem with including fundamental properties like reflexivity or transitivity. It works for some cases, but not all.
Comment by Patrick Durusau — November 9, 2010 @ 5:21 am
Another good example of a communication failure…. 😉 I was referring with “properties” to the “key/value” pairs and you mean with properties the constraints of “isa”/”ako”.
So, I don’t disagree with your statements in http://tm.durusau.net/?p=3774&cpage=1#comment-3705
I meant that TMRM does not define how the “isa” and “sub” proxies should look alike (an earlier version of TMRM contained that definition, though).
Comment by Lars — November 9, 2010 @ 12:38 pm