W3C home > Mailing lists > Public > public-data-shapes-wg@w3.org > January 2015

Re: Bob is not a shape [Was: Re: Shapes are Classes, even if you don't use rdf:type]

From: Eric Prud'hommeaux <eric@w3.org>
Date: Mon, 26 Jan 2015 07:11:00 -0500
To: Jerven Tjalling Bolleman <jerven.bolleman@isb-sib.ch>
Cc: public-data-shapes-wg@w3.org
Message-ID: <20150126121058.GB22276@w3.org>
* Jerven Tjalling Bolleman <jerven.bolleman@isb-sib.ch> [2015-01-26 11:38+0100]
> Hi Eric,
> 
> You are ignoring the fact that global shapes like global classes can
> introduce constraints where they are not applicable. Because my
> <ContactShape> might not be your <ContactShape>. If there was a
> <ContactShape> inside the http://xmlns.com/foaf/spec/index.rdf file
> then that <ContactShape> would still be active in anyone
> who imported/merged that file. With no way to turn them on or off
> other than deleting the <ContactShape> triples. Introducing the
> shape from class separation is a fake solution. Because like it or
> not Shapes (in ShEX) are still global constraints! Maybe just stored
> in a different file/graph than the class definition, if your lucky.
> 
> What is _really_ missing is an explicit statement about when a
> constraint is applicable, and a way to turn them off and on. Which
> apparently Dimitris already figured out in RDFUnit, and should be
> implemented in the WG end result spec.

I completely agree that my use of foaf:Person in a contacts DB may
not, and probably won't correspond with yours. The predicate
ldom:classShape should be used only when applicable; attaching it to a
foaf:Person creates the problem you describe and is precisely what I'm
trying to avoid. TQ's SPIN products currently add global constraints
to reusable classes like foaf:Person. While perhaps less than optimal,
ldom:classShape could at least simplify the migration path to a model
with non-global constraints.


I think we're actually arguing for the same solution, just factored
slightly differently. You propose:

  foaf:Person 
    rdfs:subClassOf foaf:Agent ;
    ldom:property [
      ## something magic here to indicate applicability of constraint ##
      ldom:recordConstraintFor <MayoContactDatase> ;

      ldom:predicate foaf:givenName ;
      ldom:valueType xsd:string ;
      ldom:minCount 1
    ].

I propose:

  mayoHR:ContactShape 
    ldom:property [
      ldom:predicate foaf:givenName ;
      ldom:valueType xsd:string ;
      ldom:minCount 1
    ].

  ## something magic here to indicate applicability of shape ##
  <MayoContactDatase> ldom:recordStructure mayoHR:ContactShape .


There will be lots of ways one associates constraints or shapes with
nodes and this WG will probably identify a few patterns. Other groups
will provide more just as WSDL provided a way to associate a node in
an XML message with an XML Schema and other groups have uses XML
Schema for RPC, code generation (w/ or w/o data binding), etc.
<https://www.w3.org/2014/data-shapes/wiki/ISSUE-5:_Resource_Shape_Association>
gets at some of these. Axel mentioned others which could be expressed:

  [ a ldom:QueryGraphConstraint ;
    ldom:onGraph <SomeGraph> 
    ldom:withQuery "SELECT ?s { … }" ;
    ldom:hasShape mayoHR:ContactShape ] .

LDP2 could define them for containers for which a graph root was
POSTed:

  [ a ldp:RootedPOSTConstraint ;
    ldp:onContainer <SomeLDPContainer> 
    ldom:hasShape mayoHR:ContactShape ] .

or when a query should match exactly once:

  [ a ldp:QueriedPOSTConstraint ;
    ldp:onContainer <SomeLDPContainer> 
    ldom:withQuery "SELECT ?s { … }" ;
    ldom:hasShape mayoHR:ContactShape ] .

This list goes on, as it should; we're building a useful tool here.


> Regards,
> Jerven
> 
> 
> On 26/01/15 10:57, Eric Prud'hommeaux wrote:
> >* Holger Knublauch <holger@topquadrant.com> [2015-01-26 11:27+1000]
> >>On 1/26/2015 11:21, Peter F. Patel-Schneider wrote:
> >>>-----BEGIN PGP SIGNED MESSAGE-----
> >>>Hash: SHA1
> >>>
> >>>If shapes cannot be the object of rdf:type triples, then they probably
> >>>should not be considered to be classes.
> >>
> >>Yes, the updated LDOM design has
> >>
> >>     rdfs:Class rdfs:subClassOf ldom:Shape
> >>
> >>which makes the term "Shape" more general than "Class". All classes
> >>can play the role of a shape, which means that wherever a function
> >>needs a Shape as an argument, a Class can be used too. Which in turn
> >>means that nobody really has to instantiate "Shape" unless they want
> >>to make clear that this is just meant to be an abstract description
> >>of constraints that should never be instantiated. And I can see that
> >>this distinction can make sense sometimes, e.g. in
> >>ldom:ShapeConstraint.
> >>
> >>(Classes of course have other characteristics not covered by Shape,
> >>which makes the conceptual hierarchy between the two terms less
> >>clear - the above is just a pragmatic definition in the context of
> >>LDOM execution).
> >
> >We're spending time trying to coerce our general shapes language to
> >work in a system designed only for global shape constraints. It seems
> >much more efficient to add SPIN support for a predicate that connects
> >classes to shapes. This would enable SPIN's current deployment of
> >global shapes and enable a large market with use cases that where
> >global shapes would be a harmful oversimplification.
> >
> >"All classes can play the role of a shape" doesn't imply any class
> >relationship; it just says they're not disjoint. In fact, they are
> >disjoint by almost any class definition that we find in the wild.
> >
> >   foaf:Person
> >   ┃ The Person class represents people. Something is a Person if it is
> >   ┃ a person. We don't nitpic about whether they're alive, dead, real,
> >   ┃ or imaginary. The Person class is a sub-class of the Agent class,
> >   ┃ since all people are considered 'agents' in FOAF.
> >   ┃ — http://xmlns.com/foaf/0.1/#term_Person
> >
> >   schema:Person
> >   ┃ A person (alive, dead, undead, or fictional).
> >   ┃ — http://schema.org/Person
> >
> >   dc:Policy
> >   ┃ A plan or course of action by an authority, intended to influence
> >   ┃ and determine decisions, actions, and other matters.
> >   ┃ — http://dublincore.org/2012/06/14/dcterms.rdf
> >   ┃ (dc:PhysicalResource may be a more entertaining example)
> >
> >   uniprot:cluster
> >   ┃ Cluster of proteins with similar sequences.
> >   ┃ — http://www.uniprot.org/core/#Cluster
> >
> >   fma:Kidney
> >   ┃ Corticomedullary organ which has as its part renal pelvis shared
> >   ┃ with and connected to ureter. Examples: There are only two, right
> >   ┃ kidney and left kidney.
> >   ┃ — http://fme.biostr.washington.edu/FME/body.jsp?selID=7203
> >
> >These academic-looking conflicts warn us of a fundamental modelling
> >error: attaching constraints to otherwise reusable classes. Even if
> >the WG went along with this, we'd get, and deserve, objections from
> >public review of the specs.
> >
> >We could decide to overlook the fact that we're using the same
> >identifier to talk about people and person records in some usage
> >context, but that in turn creates more inconsistencies (read
> >"headaches") down the road when we want to use foaf:Person in another
> >context. Separating shapes from classes clearly identifies the purpose
> >of the shape and encourages appropriate reuse. For example, a contacts
> >database might be populated by foaf:Person entries like:
> >
> >     [ a foaf:Person;
> >       foaf:mbox <mailto:kontokostas@informatik.uni-leipzig.de>;
> >       foaf:givenName "Dimitris" ;
> >       foaf:familyName "Kontokostas" ]
> >
> >could have a schema like:
> >     <ContactShape> {
> >         a (foaf:Person)?,
> >         foaf:givenName xsd:string+,
> >         foaf:familyName xsd:string
> >         foaf:mbox IRI?
> >     }
> >    or in LDOM
> >     <ContactShape> a ldom:Shape ;
> >       ldom:Property
> >         [ ldom:predicate rdf:type;
> >           ldom:allowedValues foaf:Person;
> >           ldom:minCount 0;
> >           ldom:maxCount 1 ] ,
> >         [ ldom:predicate foaf:givenName;
> >           ldom:valueType xsd:string,
> >           ldom:minCount 1 ] ,
> >         [ ldom:predicate foaf:familyName;
> >           ldom:valueType xsd:string,
> >           ldom:minCount 1,
> >           ldom:maxCount 1 ] ,
> >         [ ldom:predicate foaf:mbox;
> >           ldom:valueType xsd:string,
> >           ldom:minCount 0,
> >           ldom:maxCount 1 ] .
> >
> >which indicates the use as a contact and can be used in other contact
> >databases.
> >
> >On the occasions where there are global constraints, e.g. a square is
> >a rectangle with eqivalent sides, we can attach the shape to the class
> >with a ldom:classShape predicate.
> >
> >     ex:Square
> >         a rdfs:Class ;
> >         ldom:classShape ex:SquareShape ;
> >	rdfs:subClassOf ex:Rectangle ;
> >	rdfs:label "Square" .
> >
> >Global constraints on reusable classes is pretty rare (limited to some
> >geometric and physical laws); I think examples in the doc should focus
> >on foaf:Person, arguably one of the most reused classes in all of RDF.
> >
> >
> >>Overall I think this whole discussion is just a foretaste of the
> >>difficulties that we will have in explaining the difference between
> >>those concepts to the user community.
> >>
> >>Holger
> >>
> >>
> >
> 
> -- 
> -------------------------------------------------------------------
> Jerven Bolleman                        Jerven.Bolleman@isb-sib.ch
> SIB Swiss Institute of Bioinformatics  Tel: +41 (0)22 379 58 85
> CMU, rue Michel Servet 1               Fax: +41 (0)22 379 58 58
> 1211 Geneve 4,
> Switzerland     www.isb-sib.ch - www.uniprot.org
> Follow us at https://twitter.com/#!/uniprot
> -------------------------------------------------------------------
> 

-- 
-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 Monday, 26 January 2015 12:11:10 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 January 2015 12:11:11 UTC