Duane,
I'm not sure I get your point. Assuming that the semantics of
@FirstNameOfContact is well defined and consistent (which I think is your
assumption - a big assumption), I don't see how the data contained in
@FirstNameOfContact in these 2 context have different semantics. In fact the
SAME party with the SAME @FirstNameOfContact may play the role of BuyerParty in
one XML document fragment and SellingParty in another. Clearly the same
parties semantics are consistent with its self. (01)
I think the point being made was that analysis of different-but-assumed-similar
tag names in various schema alone, without any abstraction, has less value than
understanding common abstractions with semantic mappings. (02)
I feel like we must be talking past each other somehow?? (03)
-Cory (04)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Duane Nickull
Sent: Tuesday, November 01, 2011 4:23 PM
To: edbark@xxxxxxxx; [ontolog-forum]; Paul Brown
Cc: simf-rfp@xxxxxxx; jamsden@xxxxxxxxxx
Subject: Re: [ontolog-forum] Solving the information federation problem (05)
I couldn't agree more with this: (06)
>>Yet there is much implied in the data structures that they exchange as
>>there is in the data structures that are used within each party's IT
>>systems. I see some benefit in analyzing these data structures and
>>extracting the ontological fragments they represent. There will be
>>many holes, particularly in relationships between concepts, but it's a
>>useful starting point. I see even greater advantage if we can then
>>define ontological relationships and from them generate mappi
>ngs between data structures, particularly between the publicly
>exchanged data structures and each party's equivalent internal representations.
>There's real commercial benefit here. (07)
One issue that has perplexed a few beginners is the structure affecting
semantics. Presuming we could all agree on the meaning of a data element that
is used for the "First name of a company contact", it would appear on the
surface that we have solved a problem. EDIFACT and OAGIS both took
this approach and it has many benefits. The issue comes when the data
transferred is structured differently. In Xpath terms, the data contained
within the hierarchy: (08)
//PurchaseOrder/BuyerParty/@FirstNameOfContact (09)
Is semantically different from (010)
//PurchaseOrder/SellingParty/@FirstNameOfContact (011)
The mapping between a hierarchy and a structured text file like EDI is
difficult to document when you want to preserve the more subtle nuances of
pragmatics. (012)
Duane (013)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/ Community Wiki:
http://ontolog.cim3.net/wiki/ To join:
http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (015)
|