Back to Shared Semantics

MB reiterates: no dependency between UML Packages and OWL Ontologies

Some questions: Is the UML Package to be part of the published standard?

Would hope that we standaridize in a series of specifications those things that are relevant to FIBO, and that these are standardized independently so that they can evolve independently.

Evaluation Criteria for the ontology components - will be discussed at the September 2011 Quarterly Meeting.

If UML is considered part of the standard set of artifacts that we are delivering to the OMG. Then this should be very modularized.

Each of the sets of terms will evolve independently.

Examples: Swaps may evolve independently from say Bonds, and the Global Terms material e.g. legal grammar.

SO:

Recommend these are in separate models and separate files.

These can be brought together for some overall purpose.

Consensus / discussion Can these be wholly independent? Need precise guidelines on how these can be related to each other.

Some models will be indepenent of others.

Concerns: Need a degree of precision about how they are related.

The hieraciechy should have some architecture.

Use Cases 1. Import and export 2.

Sizing

be able to standraiuse the business conceptual model and how to derive operational ontologties from that.

There are a couple considerations in this@: 1. metadat athat we need. 2. transformation rules.

THe transformation rules might be presented as an ontology. This moghe be possible. So there may be a masking map which is really just another ontology, a very light ontology consisting of those rules.

Consensus? Yes.

• Business Conceptual Ontology • Transformation rules (requries some research)

What form would these rules take?

Similar considerations may be in place to what we needed for transformation into an operational ontology, and for “Semantic Data Model” in the IBM Research PoC.

Can we take what people did by hand for the MBS PoC and the Derivatives PiC, and see what it would take to articulate that as a set of transformation rules.

Should these be part of the initial release of the Standard?

Consensus: No.

Don't even think about transforms in the initial release of the standard.

What we standardize is the conceptual ontology. There will be transformation mechanisms. If there is a demand for this, this can be delivered in subsequent release.

The OWL model used for Semantic Web applications has a lot less in it. Currently done by hand but we hope to be able to identify what some of the differences have been and formalize these.

One aspect: the conceptual model will have a lot of terms that will not have operational data (instance data)

Semantic Web applications will be focused on instance data.

Note however that in semantic web applications, the instance data is generally kept separately (lives in a separate RDF/OWL file). Apart from “rarified individuals”, these would not be in what's known in SemTech as “Primary Ontology”. (the “rarified” ones are also in the Conceptual Ontology, e.g “United States” as an individual of type Country). Leaves the ability to test things without them blowing up.

Multiple inheritance is often used in OWL as well as in the conceptual model Data models would use only single inheritance.

Question:Working from files versus “Named Graphs” in triples stores. Are these the same thing?

When using spefici tools (Mulgara, Sesame?) you would load both the types and individuals. The ontology standing by itself is useful.

Modularity: more about elements of interest than whether they are in a particular file.

With respect to SBVR on the above question: files are really about interchange files. In OMG, this is the focus. In terms of tools, could equally use a triple store, an OO database and so on.

Either of the below:

The principal difference is that one is Full and one is DL? No, not entirely. There are differences but we have not yet got to the point of understanding what they all are. Some of the use cases for the business ontology simply don't have the requirements of a semantic web application. The use case for the business ontology (which is a kind of !conceptual model“ in MDA terms) are different, and are to do with understanding and formally articulating the semantics of the terms.

Similar considerations apply in any transformation to an operational solution and a business conceptual model.

A formal business conceptual model of things and facts using OWL notation and constructs.

There would also be an OWL version of this.

Concepts and relationships are structured based on the way that business people think and speak. It is the language of the people that run the banks. It is not optimized to make reasoning engines happy.

So there is a transform (for example, to express the content in OWL-DL).

Q: Is that not an argument to do queries instead of using inference engines to construct the extra triples that are needed? (you can query against OWL Full but reasoning is against OWL DL).

• this is all implementation • We are talking about the concepts

We may be pleasantly surprised to find we can do a lot of stuff with the full ontology anyway. However, many applications (both SemWeb and relational database related) would use a fraction of the content for a given application.

An ontology which is operationally useful for semantic web applications.

This comes with limitations that do not need to be retrospectively applied to the Business Ontology.