Re: Global property constraints (was: Re: Stand-alone Shapes and oslc:valueRange implemented in SPIN)

On Thu, Dec 4, 2014 at 1:13 PM, Holger Knublauch <holger@topquadrant.com>
wrote:

>
> On 12/4/14, 7:40 PM, Dimitris Kontokostas wrote:
>
>> Taking this a little further, we should be able to define global (on a
>> graph level) property constraints without the need to assign them to a
>> Class / Shape.
>> Here's an example on how Wikidata does something similar.
>> https://www.wikidata.org/wiki/Property_talk:P1047
>> https://www.wikidata.org/wiki/Property_talk:P640
>> https://www.wikidata.org/wiki/Property_talk:P1212
>>
>
> I cannot follow this line of reasoning. All examples above are properties
> that have a domain, i.e. they are assumed to be applied to instances of a
> specific class only. Therefore, why wouldn't it be possible to attach those
> constraints to the domain class, similar to how owl:Restriction and
> oslc:Property does it? In my original comment to Eric's example, I was also
> stating that the datatype could be attached to the Item class, not globally
> on the property.
>
> My general opinion is that global property axioms such as rdfs:range,
> domain, and owl:FunctionalProperty are overrated and better avoided. No
> other mainstream technology seems to have such a concept of global
> properties. Even solutions like schema:domainIncludes and rangeIncludes are
> problematic, e.g. what happens if each have two values - which combinations
> are supported? If constraints are attached to classes, this is clearer.
>

This is something that if accepted we will have to be defined explicitly
(but all imo).

I am not against defining a per shape domain and range but IMHO global
property constraints should also be possible. If and to what extend the WG
will decide.
SPIN also allows this by attaching constraints to owl:Thing / rdf:Property
so global constraints are not a bad think per se.

I believe without them, duplication will be needed for the constraint
definition and duplication leads to confusion and increases maintenance
cost.
For example:
- foaf:mbox should always be a string  (datatype range), match an email
regex pattern and be unique in my RDF graph, perhaps I don't care about the
class it is used in
  - Later on I may define a class shape W3CPerson that only requires a
regex in the form "*@w3.org" and a FooPerson with "*@foo.bar" (both
constraints should be validated, the global one and the local one)
- foaf:name should always be used in a foaf:Person (domain). Violation
occurs when foaf:name is found in any other class

Closed shapes, oslc:Property sub-classing or using owl:Thing as a class can
be workarounds to this but should we tackle only high level constraints in
terms of Shapes/Classes or should we allow constraints on the property
level as well?

Best,
Dimitris



> Thanks
> Holger
>
>
>


-- 
Dimitris Kontokostas
Department of Computer Science, University of Leipzig
Research Group: http://aksw.org
Homepage:http://aksw.org/DimitrisKontokostas