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

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

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