Re: Can Shapes always be Classes?

On 11/04/2014 09:16 PM, Holger Knublauch wrote:
> I believe there is a fundamental difference in how the various proposals treat
> the relationship between resources and their shapes:
>
> - In OWL and SPIN, constraints are attached to classes. rdf:type triples are
> used to determine which constraints need to be evaluated for a given instance.

This is false for both OWL constraints and Stardog ICV.

OWL constraints utilize OWL axioms as constraints.  Although many OWL axioms 
are used to define classes not all are.  Although most OWL axioms are 
concerned with class membership not all are.  Many OWL axioms are unconcerned 
with explicit rdf:type triples.

Stardog ICV constraints are also not all like class definitions.  For example, 
Stardog ICV can be used to check domains and ranges for properties or 
subproperty relationships.  Stardog ICV can also have constraints that do not 
depend on explicit rdf:type properties in the input.  See the 
http://docs.stardog.com/icv/ for examples of all of these.  (You would have to 
simplify an example to get the last aspect of Stardog.)

> - In the original Resource Shapes and ShEx, Shapes are stand-alone entities
> that may or may not be associated with a class. Other mechanisms than rdf:type
> are used to point from instances to their shapes.

Resource Shapes and ShEx appear to work by performing type recognition and 
then type checking.   That is, they determine which objects belong to 
particular types and then validate by checking that objects belong to the 
right types.  They can do this without explicit rdf:type triples in their 
input, but they are, in effect, computing rdf:type triples and then checking 
for their existence on particular objects.

This kind of processing can be easily handled in OWL constraints.   Many kinds 
of recognition constraints can also be handled in Stardog ICV.

[...]

> Thanks
> Holger

peter

Received on Wednesday, 19 November 2014 16:30:33 UTC