Does it support a network data model or is it fixed to homogeneous tables? (01)
-----Original Message-----
From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx
[mailto:ontolog-forum-bounces@xxxxxxxxxxxxxxxx] On Behalf Of bniemann@xxxxxxx
Sent: Tuesday, November 01, 2011 1:30 PM
To: edbark@xxxxxxxx
Cc: simf-rfp@xxxxxxx; jamsden@xxxxxxxxxx; ontolog-forum@xxxxxxxxxxxxxxxx;
pbrown@xxxxxxxxx
Subject: Re: [ontolog-forum] Solving the information federation problem (02)
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 (03)
On Tue, Nov 1, 2011 at 1:08 PM, Ed Barkmeyer wrote: (04)
> 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 (05)
_________________________________________________________________
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)
_________________________________________________________________
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 (07)
|