Re: Merging Databases

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<tai@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:mail@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

Received on Friday, 24 July 2009 16:09:39 UTC