Re: [regrep-cc-review] Re: Methodology - OWL

[Duane Nickull <dnickull@adobe.com>]

Steve:

Comments inline:

Steve Capell wrote:

>Hello all,
>...  However I'm not sure I agree that only one
>interchange format is relevant or that it needs to be too tightly coupled
>to the storage model so I'm going to expose my ignorance and ask a few
>questions:
>
[DN] I don't think it needs to be tightly coupled o the storage model 
however I do believe that the serialization will create dependencies on 
the storage model which is why it should be developed first. For 
example, if the serialization needs an attribute (for sake of argument 
let's call it "foo"), then foo better be present in the storage format.

>1	The reason to have a serialization format is for inter operability between
>"consumers" of core component data right?  I expect that the most likely
>tool that will interface with a core component repository is a UML modeling
>tool.  Accordingly the repository content needs to be understood by a UML
>tool.  Despite it's imperfections, XMI is the most widespread format for
>interchange of models so a core component repository probably ought to
>support delivery of core components in XMI format. As UML2 comes into play
>and OMG's MOF work becomes more widely supported, I would have thought that
>model interchange formats will become more important and more consistent.
>
[DN] This is a requirement for the serialization format.  No group has 
finalized a set of requirements for the serialization and we should do 
that before we consider any solution.  XML is definitely one possible 
solution but if it doesn't meet the requirements, we may have to look 
elsewhere.  In general, an XML schema to define the metadata for 
serialization can include an XMI component to satisfy UML tool vendor 
needs.  I use Poseidon so I have used XMI for this before.

>2	Not all developers of e-business standards like to use a model based
>approach.  In fact many would jump straight into the XML.  The obvious
>problem with that is that there are a host of different ways that the same
>semantic content can be represented in XML syntax.  Nevertheless wouldn't it
>be nice if I could just download the re-usable components from a repository
>into my XML authoring tool?  Better still if the repository provided some
>consistent naming & design rules for the XML generation (such as the good
>work done by the UBL group and currently being adopted/modified by
>UN/CEFACT).
>
[DN It would be more than nice - it is needed.  This is yet another 
requirement for the serialization.  

>3	Then again this group might define a standard serialization format in XML
>or some other syntax that is a little different to either of the above.
>Probably for good reason - to address the limitations of XMI and to contain
>the complete CCTS model data (which UBL serialization would not do).  So now
>there is a third (and formal standard) way of representing the core
>component.
>
[D] IMHO - We need to do this however, I would prefer to list 
requirements before we start exploring solutions like XML.  My gut 
feeling is that XML will be the solution but I urge us all to be open to 
picking the best solution.  Core Components and BIE's are context 
agnostic, however in the real world, people want them to be rendered in 
a number of ways - UML, XML schema, HTML, PDF.  Only XML seems to be 
able to meet all the requirements.

>4	Unfortunately I don't have enough knowledge on OWL/RDF to comment about
>it's use for core component serialization but it is at least the foundation
>for another option...
>
[DN] OWL is written in XML syntax so choosing an XML format that can 
include things like RDF, OWL and XMI as components seems to be a wise 
and flexible solution.

>I guess what I am saying is that if I were trying to build a commercial core
>component repository that was useful to today's community, I think I would
>offer a few options for the syntax that the same core component can be
>delivered / published.  "Do you want this standard address structure as an
>XMI file for your modeling tool or as a UBL NDR compliant XSD for your XML
>authoring tool or in the standard OASIS representation?"
>
[DN] I think that a requirement is "the Core COmponent serialization 
must support multiple expressions and representations in many syntax's 
and languages, including (as a non exhaustive set) OWL, RDF, XMI, UML 
...".  If we adopt something like this, then everybody can be happy. 
 Keep in mind that one of XML's greatest powers is the ability to morph 
into other XML format, pending alignment of the object model.

>All these formats would be delivered from the same storage model so that
>storage model needs to be a superset of the requirements imposed by the
>various likely interchange formats.  So I think that both the current
>storage model work and interchange format work need to progress in parallel.
>
[DN] I disagree.  I think that the serialization work has to be done 
first because of the dependencies.  The storage work can proceed in 
parallel but must be completed afterwards.  Otherwise, the risk is that 
we do not have a storage format capable of storing the things needed in 
the serialization.

>I also think that work on serialization needs to recognise the practical
>realities of the way in which core components will be used.
>
>For example, can we consider that:
>1	Replication of a core component between repositories
>2	Publishing of new core components (eg registering a new ABIE as a context
>driven variant of an ACC)
>3	Querying the library of core components for an existing component to use
>in my message development
>all require the same data in the interchange?  Wouldn't there be lifecycle
>and ownership data in the first one that is not needed in the third one.  So
>the first one might NEED the "standard" interchange format whilst the last
>one would better use a UBL (or UN/CEFACT) compliant XSD?
>
[DN] it will.  Step one - collect requirements. ;-)

>Just some thoughts... sorry for the rambling...
>
[DN] Highly relevant and shows that you have put some good thought into 
this subject IMO.

Cheers

Duane

-- 
Senior Standards Strategist
Adobe Systems, Inc.
http://www.adobe.com