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

[John Arwe <johnarwe@us.ibm.com>]

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