Paul Brown wrote:
> When two parties interact for a purpose I think an ontology is established as
>they agree on a language of discourse to be used in their interactions. In a
>business-to-business interaction, the concepts of request for quote (RFQ),
>quote, order, shipment, invoice, and payment are examples. For this ontology
>(language) to be useful, both parties need to relate these terms to their
>respective ontologies for running their businesses. Today few (if any) parties
>explicitly craft these ontologies - they are implicit. 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 mappings
>between data structures, particularly between the publicly exchanged data
>structures and each party's equivalent internal representations. There's real
>commercial benefit here.
> (01)
We have done quite a bit of that in working on automotive supply-chain
problems, using EDIFACT, OAGIS and NA EDI exchange standards. Some
'ontological fragments' can indeed be gleaned from these specifications,
the OAGIS spec being significantly better than the EDI standards in that
regard. But the overall problem is that these specifications are
intended to accommodate a number of significantly different business
practices, which use the same information fields for somewhat different
purposes. That is, the content is nominally of the same kind, but the
interpretation depends very much on the usage. (02)
As a consequence, the 'extracted ontologies' tend to be closer in style
to upper ontologies, in that they introduce general categories with only
general business meaning. For example, the EDIFACT NAD segment (Name
and Address) actually carries whatever information you may need about an
organization playing some role in your transaction, and one of the
fields of the NAD is a code (from a standard list) that identifies the
role. The information in the NAD may be about the organization, or
about persons representing the organization in that role, or about
characteristics of the role, as opposed to the organization. In our
experience, you have to sort out these ideas -- which concepts are
distinguishable objects, and which fields are properties of which
objects, relative to the transactions that use them. The address of the
Buyer (role code) can be the delivery address for one use and the
billing address for another. The meaning of location codes gets mixed
up with the terms of delivery, and so on. It is very much a matter of
'this field is used to carry this information in this case'. (03)
The AIAG's Materials Off-Shore Sourcing (MOSS) project developed a
semantic mapping matrix that included some 1500 concepts represented in
various fields in 22 different messages, with the average concept being
represented in 5 or 6 different ways, and the average field being used
for 2-3 different concepts. The usages could all be determined from
context, but the determination rules were complex in many cases, and not
consistently parallel. (04)
So you can indeed glean a bunch of fragments, but you have to do a lot
of knowledge engineering to create the ontology that makes sense of
them. That said, we certainly found the exchange standards (and their
code sets) a worthwhile starting point, especially for conversations
involving the knowledge engineer, the domain experts, and the EDI
software experts who worked for/with the domain folk. (05)
-Ed
> -- PCB
>
>
>******************************************************************************************
> Paul C. Brown
> Principal Software Architect
> TIBCO Software Inc.
> Email: pbrown@xxxxxxxxx Mobile: 518-424-5360
> Yahoo:pbrown12_12303 AIM: pcbarch
>
> "Total architecture is not a choice - it is a concession to reality."
> Visit www.total-architecture.com
> Architecture Books:
> -- Succeeding With SOA: Realizing Business Value Through Total Architecture
> -- Implementing SOA: Total Architecture In Practice
> -- TIBCO Architecture Fundamentals
>
> The SOA Manifesto: soa-manifesto.org
>
>******************************************************************************************
>
> -----Original Message-----
> From: AzamatAbdoullaev [mailto:abdoul@xxxxxxxxxxxxxx]
> Sent: Sunday, October 30, 2011 6:01 AM
> To: [ontolog-forum]
> Cc: John F. Sowa; simf-rfp@xxxxxxx; jamsden@xxxxxxxxxx; Paul Brown
> Subject: Re: [ontolog-forum] Solving the information federation problem
>
> On Saturday, October 29, 2011 8:42 PM, John wrote:
> "But I would say that the representational types (and the schemata that
> define them) are a version
> of ontology....
> "Information federation is a problem of relating multiple ontologies."
>
> That's just right.
> The matter was discussed about 3 years ago as "ontology federation",
> "federated ontology system", "federated global
> schema", 'federated ontology architecture", and "federated local schemas":
> http://lists.w3.org/Archives/Public/semantic-web/2009Jan/0019.html
> Indeed, novelties are well forgotten old things.
>
> Azamat
>
> ----- Original Message -----
> From: "John F. Sowa" <sowa@xxxxxxxxxxx>
> To: <ontolog-forum@xxxxxxxxxxxxxxxx>
> Cc: <simf-rfp@xxxxxxx>; "Jim Amsden" <jamsden@xxxxxxxxxx>;
> <pbrown@xxxxxxxxx>
> Sent: Saturday, October 29, 2011 8:42 PM
> Subject: Re: [ontolog-forum] Solving the information federation problem
>
>
> On 10/29/2011 12:58 PM, Paul Brown via Cory Casanave:
>
>> It occurs to me that there are two distinct notions of type that are
>> relevant here: representational type (as defined in a schema), and
>> ontological type, reflecting what can happen in the real world. To me, a
>> representational type defines the aspects that are relevant (whether
>> mandatory or optional) in the context for which the representation was
>> designed. If the representational types are mapped to the ontological
>> types that they represent, then these mappings can be used to relate
>> representational types via the ontological types. This is Cory's pivot.
>>
>
> I agree that the distinction is important. But I would say that the
> representational types (and the schemata that define them) are a version
> of ontology.
>
> To give an example, consider the ontology of Amazon.com, which would
> represent real-world items that they sell, the customers who buy them,
> and the suppliers that provide them. For each of those things, their
> software would only use a small subset of the information about them.
>
> They would also require an ontology about time, space, and events
> to cover the locations of their customers and suppliers, the taxes
> for those locations, the shipping methods and times, the kinds of
> events that might cause delays (holidays, weather), etc.
>
> But Amazon would also have an ontology of their business, the
> software that supports it, and the kinds of operations for
> all the interactions with customers, suppliers, locations.
>
> What Paul calls the representational type consists of the union of
> the business ontology, the software ontology, and a very small subset
> of the ontologies for all the real-world people, places, things,
> and events that the business must deal with.
>
> This observation does not automatically solve the problem, but it shows
> how the problem can be restated:
>
> 1. Information federation is a problem of relating multiple ontologies.
>
> 2. Some ontologies may have a very large overlap, such as the ontology
> of Amazon's business with Amazon's software.
>
> 3. But other ontologies may have a small overlap with the information
> that Amazon needs. For example, a customer may be defined as a
> human being, but only a tiny subset of all the possible information
> is relevant to the operation of their software -- name, address,
> credit card, previous purchases, etc.
>
> 4. Using the same tools to format the information may simplify the
> syntactic problems, but it does not solve the semantic issues.
> Matching a supplier's RDB to Amazon's RDB is a nontrivial task.
>
> Sometimes, there are mismatches along the way. This morning I received
> email from Amazon with a notice of a big bargain:
>
>
>> Maxell Rewritable DVD+RW (15-Pack)
>> by Maxell
>>
>> List Price: $366.99
>> Price: $10.57
>> You Save: $356.42 (97%)
>>
>
> A discount of 97% sounds very good, but there was undoubtedly some
> mistake with the list price.
>
> By the way, anybody who is looking for realistic use cases for
> information federation and ontology merging should look at the
> Amazon specifications. They are publicly available, and the task
> of matching a supplier's software to the Amazon schema takes a
> considerable amount of time and effort.
>
> John
>
> _________________________________________________________________
> 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
>
> (06)
--
Edward J. Barkmeyer Email: edbark@xxxxxxxx
National Institute of Standards & Technology
Manufacturing Systems Integration Division
100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528
Gaithersburg, MD 20899-8263 Cel: +1 240-672-5800 (07)
"The opinions expressed above do not reflect consensus of NIST,
and have not been reviewed by any Government authority." (08)
_________________________________________________________________
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 (09)
|