Re: shapes and classes: different

The good thing is that once we roll out the new language, no existing 
vocabulary will already use it, so there is no legacy. Some vocabulary 
owners (hopefully SKOS and schema.org) may find value in creating 
updates that include the constraints that they always wanted to express 
but couldn't. Others may just leave the vocabularies in RDFS/OWL as they 
are now, and there are zero constraints on their use from an (LDOM) 
point of view.

If FOAF is meant to be generic, then they can leave it unspecified. In 
the controlled enterprise use cases that we encounter, people will 
likely make global constraints, and that is perfectly fine.

Holger


On 1/27/15, 9:22 AM, Irene Polikoff wrote:
> 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?
>
> 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
>>> -------------------------------------------------------------------
>>>

Received on Monday, 26 January 2015 23:30:27 UTC