ontology-summit
[Top] [All Lists]

Re: [ontology-summit] Ontology driven Data Integration using owl:equival

To: "'Ontology Summit 2014 discussion'" <ontology-summit@xxxxxxxxxxxxxxxx>
From: "Matthew West" <dr.matthew.west@xxxxxxxxx>
Date: Mon, 10 Feb 2014 08:57:09 -0000
Message-id: <00c801cf263e$151354d0$3f39fe70$@gmail.com>
Dear Paul,    (01)

Back in the good old days (early nineties in this case) this kind of problem ...    (02)


I first encountered this problem after merging product data from the PLM 
system, the shop-floor manufacturing system, and the ERP system. To take one 
example: Each system has a different property for "unit of measure", and a 
different range of values for the property. Say the properties are 
plm:UnitOfMeasure, ms:UOM, and erp:MEINS (can you guess what the ERP system 
is?). Congruent values in the respective systems might be "EA (each)", "EA", 
"EA"; "OZ (ounce)", "OZ", "OZ"; "FT^2 (square foot)", "SQFT", "FT2".
[MW>] ... would be solved using a mapping table: something like:    (03)

System 1  System 2  System 3
Oz              OZ             ounce
Ft^2           FT2            sqft
...    (04)

Of course this was quite expensive, so by the early noughties people had worked 
out that it was cheaper to get it right in the source systems, and all use one 
set of codes. The challenge here is that the codes can change over time, either 
become obsolete, or new ones be added - think of country codes as an example, 
so the question is how to decide which codes to use, and then how to maintain 
them. This is called Master Data Management. The secret is to identify the 
authoritative source for each set of codes, and use those, rather than invent 
your own (unless of course you are the authoritative source).    (05)

What you suggest below seems to me like a step backwards, even from the mapping 
table.
Regards
Matthew West    (06)

So in the data I might find:
<http://example.org/plm/part/12345> plm:UnitOfMeasure "EA (each)" .
<http://example.org/ms/part-master/12345> ms:UOM "EA" .
<http://example.org/erp/material/12345> erp:MEINS "OZ" .    (07)

I want to be able to detect cases like the 3rd statement, which is not in 
accord with the other two.    (08)

My preferred approach now is to use rules, but I found you can accomplish 
nearly the same thing in RDF by using the reification vocabulary.    (09)

First you add assertions to the repository like the following.    (010)

[a rdf:Statement; 
    rdf:predicate plm:UnitOfMeasure;
    rdf:object "EA (each)"]
  ex:equivalentPredicate [a rdf:Statement; 
    rdf:predicate erp:MEINS;
    rdf:object "EA"] .    (011)

Insert similar statements for each pair of equivalent predicates and values. 
(My OWL is too rusty at the moment to attempt to define the conditions using 
owl:equivalentClass.)    (012)

If I have some way of asserting that the subjects all denote the same thing 
(which is easy enough with SKOS), then a sparql query like this reveals the 
discrepancies:    (013)

select ?entity1 ?uom1 ?entity2 ?uom2
where {
?entity1 skos-xl:prefLabel ?xlabel;
   plm:UnitOfMeasure ?uom1 .
?entity2 skos-xl:prefLabel ?xlabel;
   erp:MEINS ?uom2 .
filter not exists {
  [rdf:predicate plm:UnitOfMeasure;
   rdf:object ?uom1] ex:equivalentPredicate
      [rdf:predicate erp:MEINS;
       rdf:object ?uom2] .
}
}    (014)

In this case I chose to use skos-xl:prefLabel to indicate that the subjects 
"are about the same thing". There are other ways to do this, either more or 
less formally.    (015)

As noted above, the same results can be achieved using rules, and in fact in my 
work I rely more on rules than on notions of equivalency. But since the problem 
statement said "using owl:equivalentClass" I thought this approach might be 
relevant. But I have only done it in RDF; there may be unforeseen difficulties 
putting it into OWL.    (016)

Regards,
--Paul    (017)

On Sun, 2014-02-09 at 08:40 +0200, Uri Shani wrote:
> Hello Kingsley and friends. I'd like to open here a clean page in 
> reference of your suggested solution in 
> http://ontolog.cim3.net/forum/ontology-summit/2014-02/msg00117.html#nid09.
> I do that since the mailing chain is pretty hard to follow by now.... 
> :)
> 
> The problem example you state is to reason about the concept 
> 'Organization' over two different (but related) ontologies A and B 
> where a:Ogranization and b:Organization represent close and possibly 
> semantically equivalent concepts.
> Your solution is to define "integrating ontology" C which imports the 
> two ontologies A and B, and defines the triple [a:Organization 
> owl:equivalentClass b:Organization .], which will now allow to reason 
> with C about this concept as an integration over A and B.
> 
> Objections to that approach have been that there will be conflicts 
> among A and B that will entangle that reasoning in C and possibly fail 
> it or produce mistakes. I would add to this that this will also add 
> much overhead and inefficiently slow process.
> 
> Alternative solution suggestion: 
> Lets define a common ontology O in which we have a single concept 
> o:Organization. Now we define "integrating" ontologies AO and BO to 
> bridge A and B with O:
> AO imports both A and O, and defines the triple [a:Organization 
> owl:equivalentClass o:Organization .] BO imports both B and O, and 
> defines the triple [b:Organization owl:equivalentClass o:Organization 
> .]
> 
> The bridges work as two separate mediators between A and B to a 
> "common" ontology in which all organizations in A and in B will be a 
> o:Organization rather than a a:Organization or a a:Organization, 
> respectively.
> How is this useful? It depends on your application: 
> We will build two mediation "networks": one flowing models of A to O1 
> (a model in ontology O), using the integrating ontology AO, and 
> another from B to O2 (another model in ontology O), using BO. These 
> are like views of the original models.
> At this point one can work on a federated data-set over the two models
> O1 and O2, being of the same ontology. 
> 
> That is an analogy to what happens in DBMS where schema play the role 
> of ontologies.
> 
> The power of the mediation process is in more elaborate examples, 
> where O may be covering many more important concepts than just 
> Organization, and represent a meaningful knowledge about organizations 
> that overlaps A and B (and possibly many more ontologies in this 
> domain). Models in O can be transformed (mediated) from all these 
> ontologies, and what is interesting here: also mediated back to their 
> original ontologies. The "combining" ontology is in our terminology - 
> a "Mediation Rule" ontology.
> 
> About our problem domain: 
> We deal with interoperability among engineering design tools, where we 
> wish to share models in one tool with models in another tool, with no 
> limit of the umber of tools. So we defined a hierarchy of commonality 
> among ontologies and with the mediation rules ontologies we are able 
> to mediate models between specific tools and models in the common 
> ontology - back and forth.
> For instance, a model in the SysML language is mediated to a tool 
> implementing the Modelica equations modeling method - and back 
> creating a collaborative process among engineers working on these two 
> very different tools on the same engineering design.
> 
> So, I suggest to apply the same approach to the problem discussed in 
> this mail thread.
> For more, see our paper: H. Broodney, U. Shani, A. Sela, “Model 
> Integration – Extracting Value from MBSE,” in MBSE, INCOSE 
> International Symposium 2013, Philadelphia, U.S (best paper):
> https://www.researchgate.net/publication/255720194_Model_Integration__
> Extracting_Value_from_MBSE
> 
> 
> 
> Regards,
> 
> Uri Shani, PhD
> Research Staff Member
> SPRINT(lead), DANSE (lead) Projects
> 
> ___________________________________
> Phone:972-4-829-6282 |
> Phone:972-4-8296282 |
> Mobile:972-54-697-6282
> E-mail: SHANI@xxxxxxxxxx
> Find me on: LinkedIn:
> http://www.linkedin.com/in/urishani Facebook: 
>http://www.facebook.com/uri.shani
>                                 IBM
> 
>      Haifa University, Mount Carmel
>                     Haifa, HA 31905
>                              Israel
> 
> _________________________________________________________________
> Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
> Subscribe/Config: 
> http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
> Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
> Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
> Community Wiki: 
> http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
> Community Portal: http://ontolog.cim3.net/wiki/    (018)


_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014
Community Portal: http://ontolog.cim3.net/wiki/     (019)


_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/   
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/  
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2014/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2014  
Community Portal: http://ontolog.cim3.net/wiki/     (020)
<Prev in Thread] Current Thread [Next in Thread>