Dear Matthew, (01)
Please see replies inline. (02)
On Mon, 2014-02-10 at 08:57 +0000, Matthew West wrote:
> Dear Paul,
>
> Back in the good old days (early nineties in this case) this kind of problem
>...
>
>
> 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". (03)
> [MW>] ... would be solved using a
> mapping table: something like:
>
> System 1 System 2 System 3
> Oz OZ ounce
> Ft^2 FT2 sqft
> ...
>
> 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. (04)
Yes, that would be ideal, but then we wouldn't be discussing the topic
under the heading of "Data integration" (or I have misunderstood the
purpose of the thread more severely than I thought possible). (05)
But for a bit of background, my use case did not arise from crufty old
legacy systems, but from brand-spanking-new "modern", "best-of-breed"
enterprise applications selected, implemented, and integrated with the
help of high-powered consultants from big-name firms. And, for the
record, I did ask them to consider harmonizing property value ranges for
this particular property as well as some others shared across systems. (06)
> 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).
>
> What you suggest below seems to me like a step backwards, even from the
> mapping table. (07)
I claimed no innovation in this approach, and wouldn't even recommend it
for general use. Since I allow rules in my architecture I prefer a
rule-driven approach. However, the thread topic seemed to restrict the
solution set to RDF and OWL, so I thought I would contribute this note
of practice. (08)
I think the challenge for ontology-driven approach is to cast the
mapping table into class definitions in a merged ontology. Right off
hand I don't see an easy way to do this. Perhaps the criteria for a
successful ontology merge in this context do not require mapping of
differing property value ranges. But as I said in my first post to this
thread, I'm coming late to the conversation, and don't want to intrude
or distract. (09)
Regards,
--Paul (010)
_________________________________________________________________
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/ (011)
|