Re: Merging Databases

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<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 20:08:16 UTC