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 [email protected] Rational Software, IBM Software Group
