ontolog-forum
[Top] [All Lists]

Re: [ontolog-forum] Solving the information federation problem

To: edbark@xxxxxxxx
Cc: simf-rfp@xxxxxxx, jamsden@xxxxxxxxxx, ontolog-forum@xxxxxxxxxxxxxxxx, pbrown@xxxxxxxxx
From: bniemann@xxxxxxx
Date: Tue, 1 Nov 2011 13:30:16 -0400 (EDT)
Message-id: <615334.929.133602e7386.Webtop.0@xxxxxxx>
Ed and Paul, Interesting discussion. I am using TIBCO's Spotfire to 
solve the information federation problem by creating an interoperability 
interface across mulitple data sources. I am proposing this right now at 
the EarthCube Charette: http://semanticommunity.info/EarthCube    (01)


On Tue, Nov 1, 2011 at 1:08 PM, Ed Barkmeyer wrote:    (02)

> 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 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.
>>
>
> 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.
> 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'.
>
> 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.
>
> 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.
>
> -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
>>
>>
>
> -- 
> 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
>
> "The opinions expressed above do not reflect consensus of NIST,  and 
> have not been reviewed by any Government authority."
>
>
>  _________________________________________________________________
> 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    (03)

_________________________________________________________________
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    (04)

<Prev in Thread] Current Thread [Next in Thread>