Differences

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

--- ws2_thursday_29_september [2011/10/05 10:57]
mikehypercube
+++ ws2_thursday_29_september [2011/10/10 07:46] (current)
mikehypercube
@@ Line 1: / Line 1: @@
 ====== WS2 Session Notes Thursday 29 September ======
+Back to [[Technical Modeling Framework]]
+Back to [[start]]
 ===== Additional Metadata as OWL Annotation Properties =====
@@ Line 32: / Line 36: @@
 The bulk of this work will be concluded off line from these sessions.
+=== Implementation: ===
+  * DC Terms
+  * SKOS terms
+  * SBVR terms
+  * New OMG change management metadata
+Much of what we are looking for is in the spreadsheet that Elisa sent. Development additional metadata terms to support this.
+Can't round trip informal stuff.
+Definition: should be in metadata.
+Develop some template for adding this stuff. We would need to add something to tooling so we want to be able to take what's in the OWL Annotation Property for "Definition", and automatically clone this into the UML "Notes" construct so that people can see it.
+We don't care so much about having "Further Notes".
+Action: Look into how to get the things in Annotation Properties and get them into the Notes construct. Would also potentially be able to make ways of accessing the content of e.g. "Further Notes" visible.
+Consensus: What if we can only clone the definition to the Notes field, and the rest is accessible via the official Adaptive interface.
+Avoid tool specific integrations where possible. Apart from the Notes field, which maps into "UML Comment" and is owned by the elements and so can be round tripped.
 ==== Rendering ====
@@ Line 63: / Line 90: @@
 From this, it seems that we will be looking to use OWL Annotation Property.
+=== Discussion ===
+We know we are going to render them as OWL Annotation Properties.
+How are we going to render the OWL Annotation Class.
+Definition of property or the instance of it?
+ - definition of the annotation
+What would we write. How we import SKOS and how the instance data looks.
+Not clear how to render it.
+Elisa's example: uses Association Class
+Consensus:
+Alternative views? Concerns are how to express the facts.
+ - that is not currently in the ODM spec. Want to update with the 1.1. ODM release, have done a lot of experiments, works consistently with built-in annotation like definedBy and stuff like DC and SKOS.
+EK will show it to MB. Can mimic this. Provide profiles.
+Migrating our profiles. Sam at EA has these profiles.
+This will be part of our big bank profile migration.
+For common metadata...
+For the specific set we are going to use, we should add a specific tag. (M assumed that's what we would see). Would be an additional profile, not part of RDF OWL profile. Express in ways that can be reused not only in ODM but in other things.
+Action: EK will have a crack at this, present and get feedback from the group.
+This may not address terms in SBVR. Would need SKOS interpreted as RDF Schema, SKOS in SBVR and so on.
+The OWL and RDF Profiles Sam Mancarella is working on. Sam is migrating those into EA. At that point, we could use those profiles.
+Meanwhile, the way of representing OWL Annotation Properties is implementation sent to Sam - this is why we would have to do the profile migration before we use the set of OWL annotation properties that we are talk.
+==== Using the new EA Profiles ====
+Suggest people use the single base class we have defined, in doing FIBO content. This should not of course limit what other people do with ODM in other contexts.
+We would was, for people editing, using or submitting FIBO stuff:
+a. Only use the single base class defined for FIBO; or
+b. Use any base class defined as valid ODM.
+Consensus:
+From Adaptive POV as long as there are precise rules defined going from ontology to UML then this would not be a problem.
+Clearly if more than one base class is used for a given OWL construct, then there will be more than one OWL construct to a given UML base class.
+Most of the issues of round tripping here would not be a problem if the stereotype is read when transforming. Previous informal transformations have not read these and have made inferences from e.g. the range.
+Processing an import: hard to know if something is in the box or not, you can't see in XMI, you only see that there are properties and what they are owned by.
+Display: somewhere you can display datatype properties either as a relationships pointing at the literal, or have in the box. If in the box, presumably it has the Literal shown as its datatype? This is something I may not have done very tidily and would be happy to refactor.
+How people want it to look when people import into their tools, of course the diagrams won't get imported with that.
+In order to get the diagrams:
+See OMG Diagram Definition standard.
+There won't be tool support for this just yet, but since that standard exists, presumably there will be in future?
+UML specification would have to take advantage of the DD Spec before we will see it in UML. UML 2.5 will possibly take advantage of the DD standard but what we are producing now will not.
 === A note on OWL Annotation Properties: ===
@@ Line 73: / Line 169: @@
 We will draft something for next week in the FIBO EA Repository and see how this looks, then fine tune it.
+==== Support for Sybase Powerbuilder and Powerdesigner ====
+Powerdesigner is the UML tool. It does not support the latest UML. API is in VB and tough to use.
+It is used in some shops. Once IMM is out, then a number of our tame UML tools will be able to support those thing. That won't affect whether someone continues to use Powerdesigner in their shop.
+There is some SBVR support in MagicDraw.
+Do we need a statement saying what it takes to play in this standard space. For instance, for the UML, would say "UML 2.x compliant". Similarly for SBVR, would support any SBVR compliant tool for SBVR experts, and any OWL compliant tool.
+SBVR should be added to the set of tooling that we support. This will not necessarily be in the current version. Not in this release but on the roadmap for the near future.
+===== What's next? =====
+ Start with the Business entity.
+Create the stand-alone piece that's the source for the standard.
+Look at eliminating dependencies.
+Dependencies - eliminate as many as possible while retaining the meaning.
+==== AOB? ====
+Sessions next week one on one for the Annotation Properties and other things.

Financial Services DTF wiki

User Tools

Site Tools

Differences

Page Tools