Re: shapes and classes: different

I seem to be explaining the same things over and over again, with no 
success. Maybe we should have a call instead and report back with a 
summary. You have my Skype contact :)

Thanks,
Holger



On 1/28/2015 8:55, Eric Prud'hommeaux wrote:
> * 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
>>
>>

Received on Tuesday, 27 January 2015 23:10:22 UTC