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

RE: shapes and classes: different

From: Irene Polikoff <irene@topquadrant.com>
Date: Mon, 26 Jan 2015 18:22:32 -0500
To: "'Eric Prud'hommeaux'" <eric@w3.org>
Cc: "'Jerven Tjalling Bolleman'" <jerven.bolleman@isb-sib.ch>, "'Peter F. Patel-Schneider'" <pfpschneider@gmail.com>, "'RDF Data Shapes Working Group'" <public-data-shapes-wg@w3.org>
Message-ID: <1b2301d039be$f9ae3ee0$ed0abca0$@topquadrant.com>
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?


-----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:
> >> 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
> >> precisely when an object belongs to them.   If you don't provide
> >> 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
> >> 
> >> 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
> > -------------------------------------------------------------------
> > 


office: +1.617.599.3509
mobile: +

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 23:23:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 26 January 2015 23:23:17 UTC