RE: shapes and classes: different

Eric,

I think this really depends on the ontology and its intended semantics. Some people, like those who designed FOAF, wanted minimum ontological commitment. Others, like those who defined SKOS or FIBO, were much more precise. They were building for reuse but with tighter semantics and boundaries. Unlike FOAF they already have constraints expressed either in OWL and/or in English language rules. It would be very natural to translate these into LDOM (or whatever name) constraints and associate them with these classes.

In addition, the question of whether one should be saying additional things about a model that has been designed as a "standard" vocabulary is somewhat philosophical. 

In RDF and Semantic Web anyone can say anything about anything. So, in principle, anyone can add constraints to foaf:Person. Whether other people want to honor, agree to and abide by these constraints is a different matter. There is a question of trust, a question of agreement and so on. And, since anyone could say anything, statements different parties make may disagree with each other. Support for such ability to let different parties say what they want and to choose what one agrees or disagrees with, I believe, is part of the overall design of RDF and Semantic Web standards. A given person and/or application can chose what they agree with and will use in a given context. And they could make a different decision in another context. Taking this perspective, it is fine to say additional things about foaf:Person especially since foaf:Person is so loosely defined that it is hard to say anything that would contradict the definition present in FOAF. Of course, one could say that foaf:Person is a boat or whatever, but this would be an intentional misuse.  

There is also a fairly common (but not universal) practice of not overloading an ontology someone else published for public re-use with additional definitions that constraints they may not have intended, but of creating subclasses and attaching your own constraints to these. Following that practice, one would create a my:Patient rdfs:subClass foaf:Person and attach constraints to my:Patient. And one can create as many different classes as they want for different contexts including hierarchies of the classes. Pretty much in the same way the hierarchies of classes are used in OO programming to share what is common and keep separately what is unique.

Any instance of my:Patient is also foaf:Person so this approach reuses foaf:Person by communicating "this is a human being" to whomever such information is valuable. This is the only semantics, I believe, creators of FOAF have intended. They didn't intend anything constrained or more specific. Contrasting with some of the FIBO definitions, for example, where they say that FIBO Person must have at least one national identification number and so on.

fibo-fnd-aap-ppl:Person
        a                owl:Class ;
        rdfs:label       "Person" ;
        rdfs:subClassOf  fibo-fnd-aap-agt:AutonomousAgent ;
        rdfs:subClassOf  [ a                            owl:Restriction ;
                           owl:minQualifiedCardinality  "1"^^xsd:nonNegativeInteger ;
                           owl:onClass                  fibo-fnd-aap-ppl:IdentityDocument ;
                           owl:onProperty               fibo-fnd-rel-rel:isIdentifiedBy
                         ] ;
        rdfs:subClassOf  [ a                            owl:Restriction ;
                           owl:minQualifiedCardinality  "1"^^xsd:nonNegativeInteger ;
                           owl:onClass                  fibo-fnd-plc-adr:PostalAddress ;
                           owl:onProperty               fibo-fnd-rel-rel:has
                         ] ;
        rdfs:subClassOf  [ a                         owl:Restriction ;
                           owl:onDataRange           fibo-fnd-aap-ppl:Gender ;
                           owl:onProperty            fibo-fnd-aap-ppl:hasGender ;
                           owl:qualifiedCardinality  "1"^^xsd:nonNegativeInteger
                         ] ;
        rdfs:subClassOf  [ a                         owl:Restriction ;
                           owl:onDataRange           xsd:dateTime ;
                           owl:onProperty            fibo-fnd-aap-ppl:hasDateOfBirth ;
                           owl:qualifiedCardinality  "1"^^xsd:nonNegativeInteger
                         ] ;
        rdfs:subClassOf  [ a                            owl:Restriction ;
                           owl:minQualifiedCardinality  "1"^^xsd:nonNegativeInteger ;
                           owl:onClass                  fibo-fnd-plc-cty:Country ;
                           owl:onProperty               fibo-fnd-aap-ppl:hasCitizenship
                         ] ;
        rdfs:subClassOf  [ a                         owl:Restriction ;
                           owl:onDataRange           xsd:string ;
                           owl:onProperty            fibo-fnd-aap-ppl:hasPlaceOfBirth ;
                           owl:qualifiedCardinality  "1"^^xsd:nonNegativeInteger
                         ] ;
        rdfs:subClassOf  [ a                            owl:Restriction ;
                           owl:minQualifiedCardinality  "1"^^xsd:nonNegativeInteger ;
                           owl:onClass                  fibo-fnd-aap-ppl:NationalIdentificationNumber ;
                           owl:onProperty               fibo-fnd-rel-rel:isIdentifiedBy
                         ] ;
        skos:definition  "A person; any member of the species homo sapiens."^^xsd:string .

Not sure if this answers the question.

Irene

-----Original Message-----
From: Eric Prud'hommeaux [mailto:eric@w3.org] 
Sent: Tuesday, January 27, 2015 3:54 PM
To: Irene Polikoff
Cc: 'Jerven Tjalling Bolleman'; 'Peter F. Patel-Schneider'; 'RDF Data Shapes Working Group'
Subject: RE: shapes and classes: different

* Irene Polikoff <irene@topquadrant.com> [2015-01-26 18:22-0500]
> This is not really a question to me, but to the group that designed 
> and maintains this vocabulary. It is a pretty "unwieldy" one although 
> may be it has gotten cleaner lately? The use case it's designed for 
> was, I believe, for people to publish information about themselves.  I 
> don't know what constraints are needed for that.
> 
> Other vocabularies that have been designed for a broad use, often have 
> constraints. SKOS has a number of constraints defined in its documentation.
> Folks that do FIBO seem to be pretty clear on their definitions and 
> constraints. I believe this is true for any other group that develop 
> vocabularies. They are the ones to decide on the constraints.
> 
> If I was to simply brainstorm, there could be a constraint that says 
> that the range of foaf:knows must be a foaf:Person. Or a constraint 
> that says you can't use both foaf:family_name and foaf:surname. It is 
> either one or the other. Or a constraint that there can be only one 
> foaf:birthday and it must be a date.
> 
> What is the significance of this question?

The LDOM proposal attaches constraints to classes, e.g.
[[
ex:Rectangle a rdfs:Class ; rdfs:subClassOf rdfs:Resource ;
  rdfs:label "Rectangle" ;
  ldom:property [
    ldom:predicate ex:height … ] …
]]

In <http://www.w3.org/mid/54C6D423.3070201@topquadrant.com>, Holger said that one wouldn't attach them to e.g. foaf:Person. His stated reason was that foaf:Person was designed for open world use, but I believe it's more about whether it's a repurposable class. It seems one should never attach constraints to the class if you may want to use that class differently in a different context.


> Irene
> 
> -----Original Message-----
> From: Eric Prud'hommeaux [mailto:eric@w3.org]
> Sent: Monday, January 26, 2015 4:50 PM
> To: Irene Polikoff
> Cc: Jerven Tjalling Bolleman; Peter F. Patel-Schneider; RDF Data 
> Shapes Working Group
> Subject: Re: shapes and classes: different
> 
> * Irene Polikoff <irene@topquadrant.com> [2015-01-26 12:24-0500]
> > > Your word shape is my word owl:Class.
> > 
> > +1
> > 
> > So, the simplest solution is not to have a new thing called Shape.
> > 
> > Another option may be to use it as a type so that some classes can 
> > be of
> type Shape as well as Class.
> > 
> > This seems to be unnecessary though as every class is already a 
> > shape. At
> minimum, even if there are no other constraints declared for a class, 
> it says that all instances belonging to it must have a certain type 
> triple. If there is a class :Person, then its instances must have 
> :Person1 a ::Person triple (whether it is asserted or inferred, 
> doesn't matter). A very minimalistic data shape, but still a shape.
> 
> What constraints would you put on a reusable class like foaf:Person?
> 
> 
> > Irene
> > 
> > > On Jan 26, 2015, at 11:12 AM, Jerven Tjalling Bolleman
> <jerven.bolleman@isb-sib.ch> wrote:
> > > 
> > > I really can't help myself...
> > > 
> > >> On 26/01/15 15:12, Peter F. Patel-Schneider wrote:
> > >> -----BEGIN PGP SIGNED MESSAGE-----
> > >> Hash: SHA1
> > >> 
> > >> The most important aspect of classes is that you state that 
> > >> objects belong to them.  If you don't state that objects belong 
> > >> to X, X is not
> a class.
> > >> 
> > >> The most important aspect of shapes is that you provide 
> > >> conditions
> stating
> > >> precisely when an object belongs to them.   If you don't provide
> conditions
> > >> stating precisely when an object belongs to X, X is not a shape.
> > >> 
> > >> Having shapes also be classes implies that you state that objects 
> > >> belong to shapes.  Having classes also be shapes implies that you 
> > >> provide recognition conditions for classes. Both situations are 
> > >> possible, but both have consequences.
> > > Your word shape is my word owl:Class. Allowing class membership
> inference from recognition conditions is as normal as class member 
> ship assertion directly in the data. But I am absolutely flabbergasted 
> that I am having this argument with one of the OWL2 editors!
> > > 
> > > Basically I am reading your response as class membership only 
> > > inferred
> is "shape membership". Class membership asserted is not "shape membership".
> Or paraphrased: Shapes only allows triples with the shape:member 
> predicate (IMO equivalent to rdf:type) to be inferred and not asserted.
> > > 
> > > 
> > >> 
> > >> peter
> > >> -----BEGIN PGP SIGNATURE-----
> > >> Version: GnuPG v1
> > >> 
> > >> iQEcBAEBAgAGBQJUxksyAAoJECjN6+QThfjzaIUH/j7/WgK+BIrFAOjM5QjLXSCI
> > >> KIeBzxvanVuXHMFiZPgtEJRKWWN0IRycb09PoNLnTDlK/wWrkoJx75Tt/eqWymiM
> > >> OKdwPp/K+nhtsLoMXQxv2rIqy5Z/n3cus9DLEMyAQTfDzHs4JOtsV5RQkHxPknrN
> > >> dRNuqOvLzPxPqxv/Uk99K4MzeKpH5DNl3vy6uECiDfnpyrcGLW3RMSPyCySOVrF6
> > >> J4HAR61iByz/FmOWc3GV+hTjIsAWBJqellRyxqKsrL/NTMeCdXSEyiwOxI9x0Vtn
> > >> SOUokrcmhGfZasxJZBC2Kw2qyO6GhG3slopAdbosgV7osNcMcmcjB57mN9vyRSI=
> > >> =Jm80
> > >> -----END PGP SIGNATURE-----
> > >> 
> > > 
> > > --
> > > -------------------------------------------------------------------
> > > 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.
> 

--
-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 Tuesday, 27 January 2015 23:52:38 UTC