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

Re: shapes and classes: different

From: Eric Prud'hommeaux <eric@w3.org>
Date: Tue, 27 Jan 2015 17:55:31 -0500
To: Holger Knublauch <holger@topquadrant.com>
Cc: public-data-shapes-wg@w3.org
Message-ID: <20150127225530.GD25535@w3.org>
* Holger Knublauch <holger@topquadrant.com> [2015-01-28 08:46+1000]
> 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.

Then why do we need it?

> >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 that's the real issue here. Does LDOM work for reusable classes?
What do we get out of it being a class?

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

Isn't any cardinality constraint on a reusable class is bad design
that should be discouraged rather than encouraged as it is in the
current model? What's the LDOM plan when folks want to avoid conflicts
by creating separate shapes?

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

Would we ever want to add restrictions to a reusable class that
weren't already in OWL?

> Holger


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 Tuesday, 27 January 2015 22:55:35 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 27 January 2015 22:55:35 UTC