Re: [oslc-core] version management of OSLC specifications

[Steve K Speicher <sspeiche@us.ibm.com>]

Hi Axel,

Some responses below.

> From: Axel Reichwein <axel.reichwein@koneksys.com>
> To: oslc-core@lists.oasis-open.org
> Cc: parham vasaiely <parham.vasaiely@eads.com>,
James Conallen/Philadelphia/IBM@IBMUS
> Date: 12/03/2013 02:39 PM
> Subject: [oslc-core] version management of OSLC
specifications
> Sent by: <oslc-core@lists.oasis-open.org>
> 
> Hello OSLC Core,
> 
> I have a technical question concerning the version management of OSLC
> specifications. In the OMG OSLC4MBSE working group, which I co-chair,
we are
> currently implementing a mapping from SysML into OSLC resource shapes.
As 
> multiple versions of SysML (1.3, 1.4, etc...) exist, we are facing
a problem
> with dealing with multiple versions of corresponding OSLC Resource
shapes. 
> 
> Typically, an RDF resource description includes a reference to a resource
> type URI (e.g. the OSLC resource shape URI). Since the semantics and
> constraints imposed on SysML elements can vary from version to version,
we 
> think that we need to include in the resource description of a SysML
element
> a reference to the version-specific resource type URI (e.g. http://
> www.omg.org/sysml/block/1.3)
. On the other hand, we also think that it is 
> necessary to have a generic resource type URI (e.g. http://www.omg.org/sysml/block
> ) which identifies the concept independent of any specific version
since 
> there will be web clients which are not interested in knowing the
specific 
> version of a resource type. Our current idea is to include in the
resource 
> description of a SysML element a reference to the generic resource
type URI as well as
> the version-specific resource type URI. This would allow web clients
to very
> easily know the version-specific type URI as well as the generic type
URI. 

The approach we are heading with OSLC is that there
won't be incompatible OSLC vocabulary changes.  Classes, properties
and individuals have their own URI and mature on their own timeline defined
by the TC that owns them.

Regarding resource shapes, which indicate the whole
of a resource instance and constraints on that resource, it would be conceivable
that each shape instance would have its own separate URI.  These shapes
could be published by organizations with a large company regarding some
organizational agreements on resources, or could be defined by standards
such as OSLC, or could be tool instance specific.

If the SysML version model is to mint a new namespace
URI per version, then seems like you could treat the URIs as being opaque
and model any higher-level concepts using vocabulary such as http://dublincore.org/documents/dcmi-terms/#terms-isVersionOf
I confess I don't understand the point about what
the web client is interested in or not.  Though I do agree, that if
it is valuable for the client to have both statements at once it could
reduce roundtrips.

> 
> As we are interested in adopting an approach which is aligned with
other 
> OSLC specifications, I would like to know your perspective on this
issue. I 
> have cc'ed Parham Vasaiely from Airbus and James Conallen from IBM
who have 
> participated in our OSLC4MBSE discussions. They may reformulate our
approach
> if I haven't expressed the concern clearly enough. 

I might suggest that you contribute your use case
to https://wiki.oasis-open.org/oslc-core/VocabUseCases
and we can put on agenda https://wiki.oasis-open.org/oslc-core/Meetings/Telecon2014.01.09
for upcoming meeting to flush out any details.  I have some I'd like
to contribute by Thursday as well.

Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net

> 
> Best regards,
> Axel

> -- 
> Axel Reichwein, PhD
> CEO | Koneksys
> -------------------------------------------
> Web: www.koneksys.com
> Twitter: @AxelReichwein
> Phone: +1 404 549 8100
> Email: axel.reichwein@koneksys.com