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

* 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
> 
> 

-- 
-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 09:57:14 UTC