Re: "shape" as a relationship, not a class

On 2/10/2015 7:13, Karen Coyle wrote:
> I understand how classes create a neat "hook" for validation routines. 
> However, I'm still not comfortable with the emphasis on classes as 
> units of validation because I would prefer that we not encourage folks 
> to treat classes in RDF as if they were classes in OO. It may well be 
> that for validation we need something that approximates the OO class 
> concept, but, like the overloading of OWL for validation, I consider a 
> similar overloading of rdf:type to be a dangerous step.

This is definitely a valid question to ask and we should address it. 
Let's figure out when this overloading of rdf:type could be a problem.

On the day in 2016 when the shapes language becomes a standard, no 
existing application or published ontology will contain shape 
constraints. Also, no existing application will have activated 
constraint checking.

Application developers will make a conscious choice to activate it - 
they would include some API or would activate constraint checking mode 
on their database when the vendors have added native support. Then they 
change their application to actually do something when constraints are 
violated, e.g. they could use that information to reject incoming data. 
But they don't have to. It's a conscious choice.

The owners of ontologies will make a conscious decision whether they 
want to enrich their class definitions with constraints. If they do, 
they would typically publish a new version, announce it to the user base 
etc. They could even publish the constraints in a separate file at a 
separate URI, and users can change their owl:imports/ldom:include to 
point to that dedicated new URI. For any mission-critical ontology (e.g. 
SKOS) I would assume that people would not just carelessly add 
constraints, but they would follow a lengthy process that is transparent 
to the users.

Only if all those changes have happened, rdf:type would get a different 
meaning. And even then, it may actually be very useful to be able to 
display constraint violations as warnings that data does not fulfill the 
implicit contracts expected by the vocabulary owners.

Holger

Received on Monday, 9 February 2015 23:18:13 UTC