shape programs [was Re: shapes as classes]

I think that you mean that a shape program is something that contains 
shapes/constraints, i.e., the top-level construct of a constraint language, 
except that some proposals don't really have a top-level construct.

One problem with calling these shape programs, is that the next level down is 
very different in different proposals.  In OWL constraints, the next level 
down are constraints (OWL axioms interpreted as constraints).  In SPIN, the 
next level down consists of triples that contain a scope class and a 
constraint.  In Shex, the next level down is a set of shapes or maybe a pair 
consisting of some scoping and a set of shapes.


OWL constraints do not have to mention classes at all.  They don't even have 
to contain descriptions.

SPIN constraints are always (I think) associated with classes.  However, there 
is no need for a SPIN document to contain an ontology.  I don't think that 
SPIN can handle OWL ontologies anyway, only RDF classes.

ShEx documents don't have any notion of classes, just shapes.

In sum, one has to be prepared to have constraints/shapes not connected to an 
ontology and not even connected to classes.



peter


PS:  Is it really true that OSLC shapes define sets of graohs?  Where is this 
stated?





On 12/15/2014 09:09 AM, Arthur Ryman wrote:
> The OSLC definition of shape is orthogonal to the concept of class. OSLC
> deals with information resources that have RDF representations. An RDF
> representation is a set of triples, aka a graph. A graph is simply an
> arbritrary set of triples, which may or may not include rdf:type triples,
> and which may or may not be connected. A shape defines a set of graphs,
> namely the set of graphs that conform to the shape. In contrast, a class
> defines a set of member resources.
>
> In practice, many graphs have the characteristic that they contain a node
> that is the URI of the information resource represented by the graph, and
> this node often is the subject of one or more rdf:type triples.
> Furthermore, that node is also often the subject of many other triples
> that give properties of that node, or link that node to other nodes.
> However, this is just a pattern. It occurs because in many cases the
> information resources are hosted by an application that follows OO design
> principles.
>
> We should also make a distinction between a shape language and a shape. We
> have several proposed shape languages. Let's refer to members of a shape
> language as shape programs. At a minimum, the semantics of a shape
> language should define how a shape program defines a shape, i.e. given a
> shape program what is the corresponding set of graphs that conform to it?
>
> In OWL ICV a shape program consists of an OWL ontology. Clearly classes
> and shapes are intimately connected here.
>
> In SPIN a shape program consists of an OWL ontology with additional
> properties that use SPARQL. Again, there is a close connection between
> class and shape.
>
> In OSLC Resource Shapes, a shape program consists of a set of related RDF
> :ResourceShape resources. A shape resource lists a set of properties, so
> it has a parallel structure to a class definition.
>
> In ShEx a shape program is a set of RDF resources which can alternatively
> be represented in a special compact syntax. The connection bewteen shape
> and class here is similar in spirit to that in OSLC.
>
> In summary, since it is useful to think about data in terms of classes and
> their properties (the OO view), it follows that a shape language is going
> to have some similarities with a class language. However, RDF is not
> restricted to an OO view of data. Therefore, in a general purpose shape
> language, shapes should be able express characteristics of arbitrary
> graphs, not just those that come from OO applications.
> _________________________________________________________
> Arthur Ryman
> Chief Data Officer
> SWG | Rational
> 905.413.3077 (phone) | 416.939.5063 (cell)
>
>

Received on Monday, 15 December 2014 21:19:13 UTC