OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.
> ) 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.

Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web ->

> Best regards,
> Axel

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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]