[oslc-core] Evolving vocabularies

[James Conallen]

Some thoughts on a topic that I hope we will see discussed soon; Evolving
Vocabularies

There are already a number of applications managing RDF data that exist
today. These resources are likely to have a lot of locally defined
predicates, local to their organization and even local to the application.
At some point standards bodies get formed and begin to define more
canonical representations (including the OSLC).  As these existing
applications evolve, they will want to reuse the newly agreed upon
vocabularies.

How should this happen? Do we have any guidance on for clients and service
providers on how to migrate to new vocabularies?  What are the usage
scenarios?

In the architecture management space, we have lots of instances where
organizations define their own types of resources, to do modeling, code
generation, simulation and other types of automation. They may want to
expose these resources into an OSLC based eco-system. Clients would want to
be able to query for resources using the predicates that it knows or
expects to see in the resource.  It will also expect to see these
predicates appear in the representations. Newer clients will want to see
the new properties, while older clients will want to see the original local
or proprietary properties.  Clients will do the normal resource access
verbs GET/PUT/POST/PATCH? with a vocabulary it knows.

I can think of some approaches, and I am sure there are many more:

1) Service providers can just add new the properties to resources, keeping
the older ones in there for older clients.  But the PUT semantics for these
resources can get confusing when the same logical property has two
conflicting values.  Not sure how to handle queries in this case.

2) Clients can identify to the service provider exactly what version of
resource definition it wants to see.  The server would be on the hook to do
the right transformation (on the fly potentially).  This might work for
simple predicate upgrades, where the meaning stays the same and just the
predicate URI changes.  But when the structure of the properties changes,
transformations in both directions (to support POST and PUT) might not be
so simple.

3) We could rely on inferencing in some way providing information that
clients could use to sort out what is what. This however places a
tremendous burden on the client.

4) No migration.  If you want to use different property URIs it is just a
different type of resource.  Clients will have to deal with the fact that
there are different rdf:types for resources that are logically the same
type.

5) Service provides only provide one version of the resource shapes.  There
is a one time migration of all existing resources.  Clients expecting the
older form will not be supported.

I am hoping to start an thread of conversation to prepare us before we use
up any call time.

Cheers,

jim conallen
Rational Design Management (DM) Integration Architect, OSLC AM Lead
jconallen at us.ibm.com
Rational Software, IBM Software Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20120925/7f68bfcf/attachment-0003.html>