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

On 1/26/15, 7:57 PM, Eric Prud'hommeaux wrote:
>
> We're spending time trying to coerce our general shapes language to
> work in a system designed only for global shape constraints.

Not true. LDOM is not only designed for global shape constraints. Most 
real-world applications live in controlled environments in which even 
the owl:imports come from local copies instead of the open web. These 
applications can chose exactly which graphs they want to use for their 
tasks. They can easily create their own copies of any namespace, 
redefine constraints etc. Nobody is ever forced to merge any "global" 
constraints into a single flat graph. I would even say those whole 
Semantic Web visions are pie-in-the-sky architectures.

Also, based on the context proposal by Jerven and Dimitris, LDOM has a 
more flexible way of slicing and dicing constraint definitions that 
further erodes the very foundation of why Shapes were originally needed.

>   It seems
> much more efficient to add SPIN support for a predicate that connects
> classes to shapes.

Yes, it already exists and is called rdf:type.

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

For some cases maybe it is unwise to attach constraints to a published 
ontology, but why publish an ontology in the first place if everyone 
then uses it as they please? What is the value if people use 
foaf:firstName to point at an xsd:date? We could just as well give up on 
trying to build a better data format.


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

I disagree. The ldom:classShape above is just another way of writing 
rdfs:subClassOf. Putting that triple in there does not change anything - 
it's still a global constraint on Square. And foaf:Person is an 
unhelpful example, because it was originally designed for an open world. 
With our new language, we should start with a clean slate as mentioned 
before.

Holger

Received on Monday, 26 January 2015 23:56:54 UTC