Differences

This shows you the differences between two versions of the page.

@@ Line 1: / Line 1: @@
+====== WS2 Rolling Notes 08 September 2011 ======
+Back to [[Technical Modeling Framework]]
+===== Agenda =====
+  * Metadata requirements
+  * Implementation of those as OWL Annotation Properties
+  * Implementation of those OWL Annotation Properties in our FIBO extended ODM framework.
+**Detail**
+  * What annotation properties do we want?
+  * What APs exist that we can use
+    * e.g. DC, SKOS, SBVR
+  * Create a structure of APs in the repository.
+===== Session Notes =====
+Looking at the Barrons definition as an example, in the Legal Entity term in the current SR.
+NB: IP issues - we should probably not quote a screed of text from such a source; we could reference it.
+See also bibliographical material MB pulled out for the Barrons definition - presumably Dublin Core cover these terms.
+==== SBVR Approaches: ====
+. When we adopt a concept
+. "Dictionary basis" when the definition is in some dictionary and we have sharpened it up and made it more precise.
+Should not mix definitions in the same entry.
+==== Conclusion: ====
+Looking at "Legal Entity" entry in the current model:
+  * Remove additional definitions from the entry?
+If it's a different - no
+If it's the same (see Legal Entity) - then we can put in the ones we looked at as long as they mean the same thing, and demarcate as "Dictionary Basis", and have the official definition from one of these. This exactly mirrors what we did in the SME Review session in which this set of information was agreed upon in the model
+When the other entries mean the same thing, then referencing them is a good.
+Q: The So What question: what are people supposed to do with that?
+The audience for a business ontology is business people. If they are familiar with one of the sources, then they can identify with what the definition is.
+How we are expecting people to read them? If wording is different, some may read the definitions as meaning a different thing.
+SBVR / best practice exists for that.
+Also multilingual.
+==== One off versus maintanined references ====
+Q: If we identify the source - does that have some implication in terms of what happens when the definition is updated in the source or not?
+=== Implications: ===
+Whether we are adopting something as a snapshot of something, or if we are making a commitment to the thing, and a commitment that if it changes, our ontology also changes.
+Conclusion: We need to decide which of these to do.
+SBVR has stuff for both of these.
+If we adopt something, we can't just adopt one thing we have to adopt its meaning.
+Semantic integrity.
+=== Conclusions: ===
+. Shared Semantics: we commit to other terms
+. Financial industry: we are the master for these terms, so we reflect a snapshot in time for when we derived these.
+Implications: we need metadata for both.
+==== Correction: Terminology v Ontology ====
+What I was describing was a vocabulary or natural language dictionary (any lexicon).
+So:
+  * Ontology: Meaningful concepts, with words
+  * Lexicon: words, with meaningful concepts.
+==== MetaMetamodel ====
+We need a structure of these.
+ISO 1087 or SBVR for the concept names.
+Q: Is SBVR or ISO 1087 to be treated as the definitive source fo rthe metadata items that we need, which we find in SBVR?
+SBVR adopted the definitions and mostly adopted the terms. Sometimes, local terms for the same meaning for some of these.
+Definition centric: adopted the concept if we adopted the definition.
+SBVR has a Source Reference showing where an SBVR term is adopted from in ISO 1087.
+==== How to implement this: ====
+Elisa has a way of doing this graphically on the ODM Profile. Fine as a fall back but may be tedious to do for everything.
+Recommend we have an extension to the ODM Profile, for the ones we want to use.
+Another suggestion (EK not keen): variant of the Documentation field but use RDFa in that documentation field.
+==== Possible approaches: ====
+. Use of HTML in the Notes field
+ - EA does not support that. Can import HTML but have own internal format for it, but would lose the semantics of the <span>s and things.
+<span> was just an example, you can use any HTML markup.
+UML has no reason not to use HTML. MD supports, as does Rational.
+===== Metaterms Approaches =====
+. Have extension of the profile with tags for each property (hard coding the property into the source
+. HTML
+. Graphical approach
+has separate shape, stereotypes by RDFS Literal from each property, and a dotted line from each item to the rdfs literal, and an association from the line to the AP that is instantiates.
+Two dependencies: 1 from the item to the literal; another dependency from the dependency to the AP, showing that it is an instance of that AP (dashed line, being Dependency).
+==== Structure: ====
+Can achieve this by defining the properties on abstract stereotypes, and then for the real properties we want to define, ...
+Example: abstract stype called Provenance Item, with tagged values for each of the things to do with provenance, and then  the real things like e.g. OWL Class, would inherit from that stereotype (in the Profile), so as to get the tagged values.
+SBVR: Do we have OWL Annotation Property definitions for the SBVR constructs that we need?
+No. SBVR defines what they are and how they work, but does not stipulate how they are implemented.

Financial Services DTF wiki

User Tools

Site Tools

Differences

Page Tools