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

It sounds like there are at least two separate
issues here.  Perhaps more.

OSLC does not limit how many resource
shapes "apply" to a given resource.  *If* one uses the oslc:instanceShape
property to find resource shape(s) from a resource, then most if not all
existing OSLC specs would lead you to expect at most one such link.  But
no such limit is expressed in OSLC Core Common Properties [1].  If
you have other, perhaps domain-specific, ways to find resource shapes then
you can use the rules Axel cited for testing the "applies to"
condition.

oslc:instanceShape is oriented towards
resource modifications, as its description says; there's also a cautionary
note about caching them.  Resource shapes generally have other uses,
such as advertising query result shapes and constraints on creation request
inputs.  In other words, the context of usage in the interaction may
influence which shape(s) a client should use for a given interaction, even
for a single "class".

Some folks have been talking in background
about the potential for using resource shapes to express the content of
specifications in a machine-readable fashion; the current "resource
definition tables" you'll find in virtually every OSLC spec can be
expressed as resource shapes.  This usage is probably closer to what
you're looking for for SysML, from what I see in Axel's emails.

[1] http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixA?sortcol=table;table=up#OSLC_Properties

Versioning I'd argue is an orthogonal
issue; one potential use of resource shapes is to express the constraints
that a "version" of something represents (and these constraints
may be further refined based on the same interaction contexts applicable
in general, like those above).  Given that OSLC already allows >1
shape to apply to a resource, and given (via the Open World Assumption
inherited from RDF) it allows >1 way to find resource shape(s) that
describe constraints for a particular context-specific interaction, the
versioning question (more likely: questions) revolve around "how"s
... how to find them, from where, how to acquire the contextual knowledge.

In Axel's example, there is a generic
and one version-specific URI.  I'd want to know if it's really only
one version-specific URI ... usually it's not.  Using typical version
schemes, a 1.3 anything is also a 1.1 and a 1.2 of the same generic thing.
 If you say that only 1.3 is formally exposed in the representations,
then either adoption will be slowed (waiting for any existing clients to
be updated to handle 1.3 resources, since they no longer "look like"
1.1 or 1.2 in the versioning tests), or you have some inferencing system
(which clients typically eschew, if that's RDF-based inferencing), or you're
relying on clients interpreting the URI structure ("cracking them
open") which violates the URI opacity " Good practice" in
WebArch, or something similar ... the details matter.  The easy way
out (for clients) is to say that providers have to expose all the version-specific
URIs that they "can".  That's pretty simple in the instanceShape
case; the semantic intent is less obvious in cases like creation factories
(if a factory says it can produce versions 1.2 and 1.3 and 2.0, should
a client conclude that it gets back a resource "of" at least
one of those versions (boolean OR), all of them (AND), or some more esoteric
combination like "1.2 and 1.3 OR 2.0").

[2] http://www.w3.org/TR/webarch/#uri-opacity

Best Regards, John

Voice US 845-435-9470  BluePages

Tivoli OSLC Lead - Show me the Scenario