Re: Stand-alone Shapes and oslc:valueRange implemented in SPIN

* Holger Knublauch <holger@topquadrant.com> [2014-12-03 11:21+1000]
> On 12/3/2014 7:09, Arthur Ryman wrote:
> >Holger,
> >
> >I've looked at your proposal. My summary is that you've defined the
> >semantics of the Resource Shape vocabulary in terms of SPIN constraints.
> >The result is that you can add oslc:property triples to any owl:Class and
> >the SPIN engine will validate the constraints defined in the Resource
> >Shape spec. You also allow oslc:valueShape to refer to any owl:Class
> >instead of just oslc:ResourceShape instances. This is very elegant. Nice
> >work!
> 
> Glad to hear that.
> 
> >
> >I have not reviewed your SPARQL translations for correctness with respect
> >to the intention of the Resource Shape spec (which is informal). I hope
> >the WG will define a set of common, high level constraints, define their
> >precise semantics, and produce equivalent SPARQL, and possibly other,
> >translations of them.
> 
> I wasn't exactly sure what oslc:valueShape was supposed to mean:
> Shall all values of the property match the given shape, or shall
> only some (i.e. at least one of them). In my current design (not yet
> published) I am therefore distinguishing between two properties
> "all" and "some" similar to how OWL does it with owl:allValuesFrom
> and owl:someValuesFrom. I believe this covers most use cases, and
> for more complex cases (qualified with "at least 2" etc), a
> fall-back could be to use SPARQL directly.

My understanding from the F2F is that one can provide multiple
restrictions for a property and they'll be effectively treated as
qualified cardinality constraints. In a OWL/Turtle, that would look
like (substitute C1, C2, S1 and S2 with ints and class defintions):

  <S0> rdfs:subClassOf 
    # C1 p arcs with object matching <S1>
    [ :onProperty <p> ; :allValuesFrom <S1> ; :cardinality C1 ],

    # C2 p arcs with object matching <S2>
    [ :onProperty <p> ; :allValuesFrom <S2> ; :cardinality C2 ],

    # every p arcs has an object of <S1> or <S2>
    [ :onProperty <p> ;
      :allValuesFrom [
        :unionOf (<S1> <S2>)
      ]
    ] .

As a concrete example, HL7 RIM reuses a generic collection to capture
e.g. a patient's given and family name name:

ShExC:
  start= <NameShape>
  <NameShape> {
    dt:COLL.item { err:person-name-family LITERAL },
    dt:COLL.item { err:person-name-given LITERAL }+
  }

Resource Shapes:
[[
  <NameShape> a rs:ResourceShape ;
      rs:property [
          rs:name "COLL.item" ;
          rs:propertyDefinition dt:COLL.item ;
          rs:valueShape [
              a rs:ResourceShape ;
              rs:property [
                  rs:name "person-name-family" ;
                  rs:propertyDefinition err:person-name-family ;
                  rs:valueType shex:Literal ;
                  rs:occurs rs:Exactly-one ;
              ]
          ] ;
          rs:occurs rs:Exactly-one ;
      ] ;
      rs:property [
          rs:name "COLL.item" ;
          rs:propertyDefinition dt:COLL.item ;
          rs:valueShape [
              a rs:ResourceShape ;
              rs:property [
                  rs:name "person-name-given" ;
                  rs:propertyDefinition err:person-name-given ;
                  rs:valueType shex:Literal ;
                  rs:occurs rs:One-or-more ;
              ]
          ] ;
          rs:occurs rs:Exactly-one ;
      ] .
]]

Here the name shape has one dt:COLL.item with a family name and one or
more dt:COLL.items with a given name.


> Holger
> 
> 

-- 
-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 Wednesday, 3 December 2014 17:57:35 UTC