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

Re: shapes and classes: different

From: Holger Knublauch <holger@topquadrant.com>
Date: Wed, 28 Jan 2015 08:46:12 +1000
Message-ID: <54C81534.70301@topquadrant.com>
To: public-data-shapes-wg@w3.org
On 1/28/2015 6:54, Eric Prud'hommeaux wrote:
> 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 … ] …
> ]]

LDOM uses classes to organize constraints. Just like "shapes" organize 
constraints into groups. There is no substantial difference, it's just 
another term for the same thing. Just like in OWL, defining a class 
doesn't mean that anybody is expected to directly instantiate it - it's 
just the definition of common characteristics.

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

I didn't say that. All I said that foaf:Person is probably not the best 
example because it has a long history of open world use. The ultimate 
decision of whether the FOAF designers want to define constraints or not 
is up to them.

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

The designers of the ontology should be allowed to make that choice. In 
many cases it makes sense to have global constraints. Take SKOS for 
example. skos:broader should have strings as values. If someone assigns 
an xsd:date then they should not use that property in the first place. 
Then skos:broader should only have at most one value per language tag. 
This allows SKOS-based tools to make assumptions that there will only be 
one label to display per concept. Without such assumptions, what use 
would any ontology be?

Received on Tuesday, 27 January 2015 22:46:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 January 2015 22:46:47 UTC