Hello Pat,
A long and interesting answer. I've got no time to answer on all points (many
of them making much sense, I have to acknowledge). I'll start focusing on the
following paragraph...
Is it symmetric (A skos:exactMatch B implies B skos:exactMatch A) and
reflexive (A skos:exactMatch A) ? Because if it is all three of
symmetric, reflexive and transitive then it is an equivalence relation,
and if it is also substitutive, then it IS equality (owl:sameAs),
whether the "reference documentation" admits this or not.
Well, it is sym, refl and trans, but it is not "globally" substitutive (A skos:exactMacth B does not imply that A and B can be substituted for *all* RDF statements).
The problem is that this is indeed not defined other than in prose. How to do it formally? We cannot even say that skos:exactMatch and owl:sameAs are disjoint properties, since they may very well share a part of their extensions.
The fact is that it may be substitutive for some properties (is such wording
meaningful in formal terms? I hope so...), and in fact it is our hope. But we
could not specify the axioms that specify such substitution rules, because we
cannot anticipate all uses of SKOS concepts (in terms of properties that would
have SKOS concepts as subjects or objects).
We could think of some axiom pattern, in the line of "there exists somewhere a
property for which substitution shall be done". But would it have helped much, in
terms of the RDF inferences you are calling for?
So, yes, this story is to some extent hot air. In fact exactMatch defines an
equivalence relation, but beyond that nothing is known, because the
substitution should be done on constructs that are not in the SKOS vocabulary.
To answer your question, shall you substitute A and B? Well, it's your pick:
you have to decide for which properties they should be substituted. We could
not invent them for you!
Actually there was one skos:subject having skos:Concept as range in the
previous version of SKOS, which could have been ok for such substitution
rules---if a document has subject A, and A is exactMacth of B, then the
document has B as subject. But it was removed, as clearly less in SKOS' scope
than in other vocabularies', such as Dublin Core.
About inconsistencies due to the use of exactMatch, they may mainly emerge when
comparing with the extension of other semantic relations, as contributed in
other mappings or concept schemes. For instance, skos:exactMatch is disjoint
with skos:broadMatch and skos:relatedMatch
Finally, about skos:relatedMatch, I'm sorry for having been too blunt, it has indeed some semantics, in the form of domain and range: you could use relatedMatch with for all cases with seeAlso, but then a number of document resources would be classified as SKOS concepts. Which would raise some inconsistencies if appropriate disjointness axioms are captured. But again, we cannot ourselves list all the classes that are disjoint with SKOS concepts. And you may argue that this is still very basic semantics, that the normative side is paramount here. You're right, skos:related is supposed to be used for relationships in existing controlled vocabularies that are extremely diverse.
Now, does that still make it meaningless to introduce it? Well, it does correspond to existing practices, and is used in a lot of data out there, which can be exploited in a large number of interesting scenarios...
Best,
Antoine
On Jul 23, 2009, at 4:24 AM, Antoine Isaac wrote:
Hello,
Trying to add some explanation wrt. the SKOS vocabulary, hoping not to
conflict with Pat's clarifications ;-)
For skos:exactMatch, the SKOS reference says [1]:
The property skos:exactMatch is used to link two concepts, indicating
a high degree of confidence that the concepts can be used
interchangeably across a wide range of information retrieval
applications
So there can be substitution. But, contrary to what happens with
owl:sameAs, this substitution is not automatic for *all* RDF triples
the concept would be involved in. Actually it is left to implementers
or ontology provider to define in which "context" two exactly
equivalent concepts may be substituted.
To me, that makes this almost completely useless, and actually harmful
to interoperation: for I have (the code I write has) no way to know what
"context' is intended when reading such an assertion. Here I am with
some RDF, and I am told that A skos:exactMatch B. Can I substitute B for
A in my content? Nobody knows. The SKOS documentation doesn't know.
Nothing in my RDF tells me the answer. I have no way to know where to go
to discover the answer. If I decide to go with my high degree of
confidence and make the inference, and in fact it wasnt appropriate, how
will I ever discover this? What kind of formally detectable
inconsistency would lead me (my code) to conclude that a mistake had
been made, and where? Without some answers to some of these (obvious)
questions, skos:exact Match might as well be called
skos:SpongeBobSquarePants.
As a (fictious!) result, one concept may be substituted by another if
it is the object of a dc:subject statement, but not if it is the
subject of a dc:creator statement.
The idea was really to be able to state some form of semantic
equivalence that would be less committing than the RDF/OWL one.
And the problem, which this conspicuously fails to address, is how to
make semantic sense of this idea of "semantic equivalence which is less
committed". Until one does, calling it "semantic" is just hot air.
Here's the central issue. The actual semantics of owl:sameAs is defined
as co-reference. It does not mean that there are two things, A and B,
which are equivalent in a strong sense (which can be weakened, no doubt,
if we only think about it for a bit.) A sameAs B means that the two
names 'A' and 'B' denote the very same thing. So if A sameaAs B, there
is ONE THING with two names. That is what the semantics specifies. But
**being the very same thing as** is not something that admits of
weakening or can be given degrees of commitment. Two very similar things
can be more or less similar, but one thing cannot be
slightly-not-the-same as itself. You can't be partially or approximately
the same as yourself, because any relation other than identity requires
the relationship to hold between TWO similar but non-identical things,
and it is the very point of identity - sameAs - that when it holds,
there is only ONE thing there. Now, turn this around. What other
semantically defined circumstances would sanction substituting the name
A for the name B in some assertion, **except** that A and B denote the
same thing? Remember, to count as 'semantic', the criterion has to be
stated in terms of what the names denote, not in terms of the names
themselves. So 'A' denotes some thing, A, and 'B' denotes B, and we want
some conditions on A and B, not on 'A' and 'B', that is enough to
justify taking something said using the name 'A' and treating it as
being said using the name 'B' instead. If A and B are different, what
would give anyone a licence to transfer truths asserted about one of
them to similar-but-different truths asserted about the other? What kind
of "context" would this be, that permits such blatantly invalid inferences?
Hopefully you can see that a genuinely semantic analysis of this
situation is somewhat difficult. You don't get it by inventing
plausible-sounding relationship names, providing no axioms for them, and
then being deliberately vague about what they mean and calling this
'reference documentation'.
Now, skos:exactMatch is transitive, which means that if a concept X in
one vocabulary has been mapped to Y in a second vocabulary, and Y is
connected to Z in a third vocabulary, then X and Z can be substituted.
Is it symmetric (A skos:exactMatch B implies B skos:exactMatch A) and
reflexive (A skos:exactMatch A) ? Because if it is all three of
symmetric, reflexive and transitive then it is an equivalence relation,
and if it is also substitutive, then it IS equality (owl:sameAs),
whether the "reference documentation" admits this or not.
This can (and will) be useful, but may be also harmful if the two
mappings were created with different application concerns in mind,
IF?? Of COURSE this will happen.
and that negligible semantic differences over a one-step mapping add
up to a bigger lap over a longer path.
and OF COURSE that will happen. This effect has been noted and written
about for many years. It is often called the heap paradox. It is the
béte noir of all attempts to give a precise semantics for concepts with
'fuzzy' boundaries. There are probably around a dozen precise
suggestions, none of which are universally accepted, for getting around it.
closeMatch is meant to deal with a lesser level of commitment. As
written in the SKOS Primer,
skos:closeMatch is not defined as transitive, which prevents such
similarity assessments to propagate beyond these two schemes.
Imagine that for a specific application you are creating mappings
between two vocabularies. You can thus create these mappings without
bother with the possibility that these links may cause dubious
substitutions for a different applications.
And also without the bother of the links creating any new entailments or
inferences for your applications. What do you even mean by a "link", if
this has no semantics to support any entailments?
SKOS has also other mapping properties, esp. a skos:relatedMatch could
be the anchor for the more specialized properties that Alan has in OBO.
This skos:relatedMatch has really not much semantics (even informal
ones) but I feel it would still be better than rdfs:seeAlso.
Why do you feel that? Two properties which are both normatively declared
to have no semantics are equally meaningless.
According to RDFS spec [3]
The property rdfs:seeAlso specifies a resource that might provide
additional information about the subject resource.
As far as I understand it (and keeping to the distinctions made e.g.
in [4]) this means that rdfs:seeAlso can connect a non-document
resource to an information resource
And what is to prevent this being the case for two resources connected
by skos:relatedMatch ? You said it has no semantics....
Pat
, which I feel is a bit too broad for Alan's case...
Cheers,
Antoine
[1] http://www.w3.org/TR/skos-reference/#mapping
[2] http://www.w3.org/TR/skos-primer/#secmapping
[3] http://www.w3.org/TR/2000/CR-rdf-schema-20000327/#s2.3.4
[4] http://www.w3.org/TR/cooluris/#distinguishing
On Jul 21, 2009, at 7:26 PM, Alan Ruttenberg wrote:
On Tue, Jul 21, 2009 at 1:23 PM, Toby Inkster<t...@g5n.co.uk> wrote:
On Tue, 2009-07-21 at 19:52 +0300, Bernhard Schandl wrote:
I would say: Never assert sameAs. It's just too big a hammer.
Instead use a wider palette of relationships to connect entities
to other ones.
which ones would you recommend?
skos:exactMatch = asserts that the two resources represent the same
concept
Say, refer to the same thing.
, but does not assert that all triples containing the first
resource are necessarily true when the second resource is substituted
in.
I'm having trouble parsing this one. I don't know what concepts are,
but they are an odd sort of thing if they can be the same, but can't
be substituted.
This is exactly what is needed in many cases. Philosophical
terminology is that they have the same referent but not the same
sense, and lack of substitutability reflects the unfortunate but
inevitable fact that the Web as a whole is not referentially
transparent (yet). More mundane example, the same person might need
to be referred to in one way in one context and differently in
another, just because the two social contexts require different forms
of address. (That example from Lynn Stein.)
In any case, this isn't much better when the issue I point out is that
there is a specific relation between e.g. the intervention and the
drug - that relation is no where near equivalence in any form.
True, but in cases like this, it is simply a basic conceptual mistake
to be using any kind of loose-sameAs property. rdf:seeAlso would be
more like what is needed for linking a drug to an intervention. I
agree with you about having a selection of better-thought-out
relations rather than just using sameAs as a kind of all-purpose
knee-jerk connecting link. Maybe this "Linked Data" slogan has a
rather dumbing-down effect, as it suggests that 'link' is a simple
uniform notion that works in all cases.
skos:closeMatch = same as exact match, but slightly woolier.
Seems harmless, assuming one doesn't mind whatever one is dealing with
typed a concept.
Ditto the broader and narrower relations, which although not to my
taste (i don't how to tell when they hold) are certainly better than
using sameAs.
owl:equivalentProperty = if {X equivalentProperty Y} and {A X B} then
{A Y B}. In other words, the properties can be used completely
interchangeably. But perhaps there are other important differences
between X and Y, such as their rdfs:label or rdfs:isDefinedBy.
Still near equivalence.
owl:equivalentClass = if {X equivalentClass Y} then all Xs are Ys and
vice versa. Same dealy with owl:equivalentProperty really.
Ditto.
ovterms:similarTo = a general, all-purpose wimps' predicate. I use
this
extensively.
Under the principal "first do no harm", this seems to work, although I
note that the intervention (something that happens) isn't similar to
the drug used in it (something that is consumed when the intervention
happens).
seeAlso seems pretty harmless and noncommittal.
But better is probably to look more closely at what the entities are
and then choose a relationship that better expresses how they relate.
In the case of the intervention, one plausible interpretation is that
the "intervention" names a class of processes, and that there is a
subclass of such processes in which the drug participates. (the other
subclass are those in which a placebo is the participant) This can be
modeled in OWL.
(My real advice for clinical trial resource is to collaborate with the
OBI project and use terminology that is being developed for exactly
that purpose)
In my line of work I start with the OBO Relation ontology,
http://www.obofoundry.org/ro/ which provides a basic set of well
documented relations, such as the has_participant relationship.
OWL also provides some relations of beyond equivalences - subclass
relations are an option, when appropriate, as well as making
statements that classes overlap - by expressing that the intersection
of the two is not empty.
That ontology is undergoing some reform, as it should in time. Some of
the new candidate relations are documented in links from that page. In
addition it is proposed that that there be class level and instance
level versions of the relations - the class level relations might
better a modeling style that would rather avoid using OWL
restrictions, and fits well with OWL 2 which allows a name(URI) to be
used as both a class and an instance.
Finally, for those cases where there are more than one URI and they
*really* mean the same thing - why not try to get the parties who
minted them to collaborate and retire one of the URIs. If they really
mean the same thing there should be no harm in either party using the
other's URI.
Its not that simple, unfortunately. I'm going to make this issue the
center of my invited talk at ISWC later this year :-)
Pat
-Alan
--
Toby A Inkster
<mailto:m...@tobyinkster.co.uk>
<http://tobyinkster.co.uk>
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
------------------------------------------------------------
IHMC (850)434 8903 or (650)494 3973
40 South Alcaniz St. (850)202 4416 office
Pensacola (850)202 4440 fax
FL 32502 (850)291 0667 mobile
phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes