Re: Shapes/ShEx or the worrying issue of yet another syntax and lack of validated vision.

* Peter F. Patel-Schneider <pfpschneider@gmail.com> [2014-07-20 02:05-0700]
> 
> 
> On 07/20/2014 01:10 AM, Eric Prud'hommeaux wrote:
> >* Evren Sirin <evren@clarkparsia.com> [2014-07-19 22:55-0400]
> 
> [...]
> 
> >One of the features of Resource Shapes is that, while it *can* be
> >attached to a type, it frequently is not. Arthur Ryman spoke of this
> >[[
> >constraint language should be independent of any vocabulary or
> >ontology
> >]] — <http://www.w3.org/mid/OFF14B15B5.802B33E2-ON85257D0A.004C62E1-85257D0A.005240FE@ca.ibm.com>
> >and emphasized it in
> ><http://www.w3.org/mid/OF026C08BD.7F379A54-ON85257D15.00456170-85257D15.0047EB06@ca.ibm.com>
> 
> Taken literally, this statement is rather extreme.  Constraint
> languages that are independent of vocabularies can only talk about
> reachability and connectedness.  I don't think that this is what is
> wanted here.

I believe that's what some people want. Both RelaxNG and XML Schema
allow one to specify a type independent from the tag name.


> One can argue that particular vocabularies/ontologies should permit
> multiple sets of constraints.  I agree with this argument.  This
> does not make the constraints independent of the vocabulary or
> ontology, however.  In fact, every example of ShEx that I have seen
> is very tied to a particular vocabulary.

I think the examples that have passed by on this list combine multiple
vocabularies in ways that are not universal to uses of those
vocabularies. For example, a foaf:givenName/familyName may be required
in some contexts by optional in others. Detaching the schema from the
type makes it easy to associate those different rules with their context.


> OWL and RDFS do not fail on this point at all.  One can use OWL and
> RDFS in a very flexible manner, where there is a base ontology and
> additional axioms.  A constraint system using OWL or RDFS can work
> in a similar fashion.
> 
> Even StarDog ICV can be used in this manner.  All you have to do is
> have an overall file that imports the base ontology and separately
> constraint-imports the constraints.  Different uses can have the
> same ontology and different constraints.  Some uses can even have
> just the constraints.  One could also have a trivial modification of
> StarDog ICV that had an extra explicit input - the constraints.

I think you're proposing truth maintenance by including or excluding
ontologies from the application at different times. For instance, if I
have some interface where someone posts new bugs:

    :NewBugShape { ex:state ( ex:unassigned ex:assigned ) }

, and another for extracting the resolved bugs:

    :ResolvedBugShape { ex:state ( ex:resolved ) }

I have some <Issue1> which is posted as a new bug:

    <Issue1> ex:state ex:unassigned .

but then gets resolved (sometimes we are lucky):

    <Issue1> ex:state ex:resolved .

.

App1 posts something conforming to :NewBugShape and then polls another
interface for :ResolvedBugShapes.

With OWL CWA/UNA, I can define a new bug shape:

  :NewBugShape rdfs:subClassOf [
      a owl:Restriction ;
      owl:onProperty ex:state ;
      owl:allValuesFrom [
          a owl:Class ;
          owl:oneOf ( ex:unassigned ex:assigned )
      ] .

and the resolved bug shape:

  :ResolvedBugShape rdfs:subClassOf [
      a owl:Restriction ;
      owl:onProperty ex:state ;
      owl:allValuesFrom [
          a owl:Class ;
          owl:value ex:resolved
      ] .

but I have to add premises to my data:

  <Issue1> a :NewBugShape ; ex:state ex:unassigned .

which I will must retract/replace when polling for resolved bugs:

  <Issue1> a :ResolvedBugShape ; ex:state ex:unassigned .

You can do this with retractable premises or by forgetting graphs, but
there's some truth maintenance required.


> Argument 2 in http://lists.w3.org/Archives/Public/public-rdf-shapes/2014Jul/0076
> does not require anything that cannot be provided by StarDog ICV and
> many other constraint setups that are built on RDFS or OWL.

Let's work through a concrete example where validating a node depends
on its context. Pairing down the usual ShExC demo example, suppose I
have an interface where someone posts issues:
[[
  my:IssueShape {
      ex:reportedBy @my:UserShape,
       ex:reproducedBy @my:EmployeeShape
  }
  
  my:UserShape {
      (foaf:name xsd:string
       | foaf:givenName xsd:string+,
         foaf:familyName xsd:string),
      foaf:mbox IRI?
  }
  
  my:EmployeeShape {
      foaf:givenName xsd:string+,
      foaf:familyName xsd:string,
      foaf:phone IRI*,
      foaf:mbox IRI
  }
]] — <http://tinyurl.com/ShEx-UserEmployee>
, we have different requirements for a UserShape and an EmployeeShape.
There is, however, an intersection between them, e.g.
[[
  <Issue2> # or could be the <Issue1> from above
      ex:reportedBy   <Thompson.J> ;
      ex:reproducedBy <Thompson.J> .
  
  <Thompson.J>
      foaf:givenName "Joe", "Joseph" ;
      foaf:familyName "Thompson" ;
      foaf:phone <tel:+456> ;
      foaf:mbox <mailto:joe@example.org> .
]]

Here, we again use something retractable to say that that something
posted to this interface has certain constraints that are peculiar to
this interface:

[[
  Individual: <file:/home/eric/checkouts/FDA-TA-merge/Issue2>
      Types: my:IssueShape # <--- retract me !!
      
  Class: my:IssueShape
      SubClassOf: 
          ex:reportedBy only my:UserShape,
          ex:reportedBy some my:UserShape,
          ex:reproducedBy some my:EmployeeShape,
          ex:reproducedBy only my:EmployeeShape
  
  Class: my:UserShape
      SubClassOf: 
          ((foaf:name exactly 1 xsd:string)
           or ((foaf:givenName min 1 xsd:string)
               and (foaf:familyName exactly 1 xsd:string)))
          and (foaf:mbox min 0 owl:Thing)
          and (foaf:mbox max 1 owl:Thing)
  
  Class: my:EmployeeShape
      SubClassOf: 
          (foaf:phone min 1 owl:Thing)
           and (foaf:mbox exactly 1 owl:Thing)
           and (foaf:givenName min 1 xsd:string)
           and (foaf:familyName exactly 1 xsd:string)
  
  Datatype: xsd:string
  ObjectProperty: ex:reportedBy
  ObjectProperty: ex:reproducedBy
  DataProperty: foaf:givenName
  DataProperty: foaf:familyName
  DataProperty: foaf:name
  ObjectProperty: foaf:mbox
  ObjectProperty: foaf:phone
]]

or, in Turtle:
[[
  <Issue2> a my:IssueShape . # <--- retract me !!

  my:IssueShape a owl:Class ;
      rdfs:subClassOf [
          a owl:Restriction ;
          owl:onProperty ex:reportedBy ;
   owl:allValuesFrom my:UserShape .
      ], [
          a owl:Restriction ;
          owl:onProperty ex:reportedBy ;
   owl:someValuesFrom my:UserShape .
      ],  [
          a owl:Restriction ;
          owl:onProperty ex:reproducedBy ;
   owl:allValuesFrom my:EmployeeShape .
      ], [
          a owl:Restriction ;
          owl:onProperty ex:reproducedBy ;
   owl:someValuesFrom my:EmployeeShape .
      ] .

  my:UserShape a owl:Class ;
      rdfs:subClassOf [
          a owl:Class ;
          owl:intersectionOf (
              [ a owl:Class ;
                owl:unionOf (
                    [ a owl:Class ;
                      owl:intersectionOf (
                          [ a owl:Restriction ;
                            owl:onProperty foaf:givenName ;
                            owl:onDataRange xsd:string ;
                            owl:minCardinality 1
                          ]
                          [ a owl:Restriction ;
                            owl:onProperty foaf:familyName ;
                            owl:onDataRange xsd:string ;
                            owl:cardinality 1
                          ]
                      )
                    ]
                    [ a owl:Restriction ;
                      owl:onProperty foaf:name ;
                      owl:qualifiedCardinality 1 ;
                      owl:onDataRange xsd:string
                    ]
                )
              ]
              [ a owl:Restriction ;
                owl:onProperty foaf:mbox ;
                owl:minCardinality 1 
              ]
          )
      ] .

  my:EmployeeShape a owl:Class ;
      rdfs:subClassOf [
          a owl:Class ;
          owl:intersectionOf (
              [ a owl:Restriction ;
                owl:onProperty foaf:givenName ;
                owl:onDataRange xsd:string ;
                owl:minCardinality 1
              ]
              [ a owl:Restriction ;
                owl:onProperty foaf:familyName ;
                owl:onDataRange xsd:string ;
                owl:cardinality 1
              ]
              [ a owl:Restriction ;
                owl:onProperty foaf:phone ;
                owl:minCardinality 1 
              ]
              [ a owl:Restriction ;
                owl:onProperty foaf:mbox ;
                owl:cardinality 1 
              ]
          )
      ] .

  ex:reportedBy a owl:ObjectProperty .
  ex:reproducedBy a owl:ObjectProperty .
  foaf:givenName a owl:DatatypeProperty .
  foaf:familyName a owl:DatatypeProperty .
  foaf:name a owl:DatatypeProperty .
  foaf:mbox a owl:ObjectProperty .
  foaf:phone a owl:ObjectProperty .
]]

> It is very hard to see how ShEx constraints can be associated with
> instances of RDFS types.  I view the ability to associate
> constraints with instances of types as the most important aspect of
> a constraint system, hence my questions about how this can be done
> in ShEx.

Since it's just a DSL for Resource Shapes, one can use the same
mechanism as in Resource Shapes. The IRIs used to identify shapes in
ShEx identify the same shapes in Resource Shapes.


> peter
> 

-- 
-ericP

office: +1.617.599.3509
mobile: +33.6.80.80.35.59

(eric@w3.org)
Feel free to forward this message to any list for any purpose other than
email address distribution.

There are subtle nuances encoded in font variation and clever layout
which can only be seen by printing this message on high-clay paper.

Received on Sunday, 20 July 2014 13:58:32 UTC