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

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.

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

Received on Monday, 26 January 2015 10:38:39 UTC