Re: associating RDF nodes with shapes

I agree that doing requirements is something that we should be concentrating 
on right now.  I also agree that the two documents are very different, and 
that my version is rather sparse.  I do not agree that my version is OWL 
centric - I added in many examples from SPIN and ShEx as appropriate.

The syntax is an ASCII approximation of the presentation syntax for OWL. I 
could change that, of course, but it's a pain to add in actual syntax unless 
the page is going to be used.  Anyway the point is that this is a different 
organization of the connection, one that I feel better describes the options.

peter


On 12/16/2014 03:48 PM, Holger Knublauch wrote:
> I am not sure how to proceed here. If you want, you could start a separate
> page where we try out your structure and we copy it over when we are done.
> Your draft below is omitting too many details and is very OWL centric to be a
> direct substitution. I also don't understand your example syntax, e.g. what
> does this mean:
>
> <code>some ex:property ex:value <= constraint</code>
>
> The bigger question is: why are we writing this document at all. Shouldn't our
> goal be to collect Requirements?
>
> Holger
>
>
> On 12/17/2014 4:43, Peter F. Patel-Schneider wrote:
>> I took a close look at the node/shape association page,
>> https://www.w3.org/2014/data-shapes/wiki/ISSUE-5:_Resource_Shape_Association
>>
>> I would prefer an organization more like the following, as I think that it
>> presents a clearer picture.
>>
>>
>> Where are Shapes/Constraints Validated
>>
>> 1/ A particular node
>>
>> A shape/constraint may be validated only on a particular node in an RDF
>> graph.
>>
>> In ShEx this would be done via a validation call that explicitly contains
>> the node and the shape.
>>
>> In OWL constraints this would be done via an axiom of the form
>>
>> <code>ex:node in constraint</code>
>>
>> 2/ Nodes that are instances of a class
>>
>> A shape/constraint may be validated against all members of a class.  The
>> membership determination may be via explicit direct <code>rdf:type</code>
>> links, via class membership in some RDF-compatible semantics, or via some
>> intermediate process.
>>
>> In SPIN this would be done via a <code>spin:constraint</code> link from the
>> class to a SPIN constraint.
>>
>> In OWL constraints this would be done via an axiom of the form
>>
>> <code>ex:Class <= constraint</code>
>>
>> 3/ Nodes that have a particular property value
>>
>> A shape/constraint may be validated against nodes that have a particular
>> property value.
>>
>> In OWL constraints this would be done via an axiom of the form
>>
>> <code>some ex:property ex:value <= constraint</code>
>>
>> 4/ All nodes
>>
>> A shape/constraint may be validated against all nodes (maybe only
>> non-literal nodes?).
>>
>> In SPIN this would be done via a constraint on rdfs:Resource.
>>
>> In OWL constraints this would be done via an axiom of the form
>>
>> <code>owl:Thing <= constraint</code>
>>
>> In ShEx this would be done by a validation call that explicitly mentions a
>> shape that all nodes are supposed to match.
>>
>> 5/ Triples with a particular predicate
>>
>> A shape/constraint may be validated against all triples of a predicate.
>>
>> In OWL constraints this would be done via
>>
>> <code>ex:predicate <= constraint</code>
>>
>> 5/ Implicit
>>
>> The form of a shape/constraint might determine how it is validated.
>>
>> This is the general situation for OWL constraints.  An OWL constraint is
>> just an axiom that is supposed to be true.  Some kinds of OWL constraints
>> can be thought of being one of the types above, but other kinds of OWL
>> constraints have particular validation patterns.  For example, an OWL
>> constraint could require that a property is symmetric or transitive or that
>> the nodes that satisfy one constraint are precisely the same as those that
>> satisfy another, as in
>>
>> <code>ex:Person and some ex:SSN = ex:USResident and age > 2</code>
>>
>>
>
>

Received on Wednesday, 17 December 2014 00:39:55 UTC