Re: Global property constraints

On 12/5/2014 0:12, Dimitris Kontokostas wrote:
> 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 <http://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?

Ok, so you see global property constraints as a useful shorthand syntax, 
"syntactic sugar" to avoid having to repeat the same statements over and 
over again. I can certainly agree that this is desirable.

But let's look at specific examples. You mention foaf:mbox, let me allow 
to use schema:email for now.

     http://schema.org/email

Its domain includes ContactPoint, Organization and Person.

Solution 1: Yes, we could introduce global equivalents of all local 
restrictions, e.g.

     schema:email
         a rdf:Property ;
         :valueType xsd:string ;
         :pattern "someRegex" ;
         :domainIncludes schema:Person ;

     schema:Person
         a rdfs:Class .

     schema:W3CPerson
         a rdfs:Class ;
         rdfs:subClassOf schema:Person ;
         :property [
             :predicate schema:email ;
             :pattern "W3Cregex" ;
         ] ;

Solution 2: Alternatively, let's do what most OO systems do, and 
introduce a "-able" class:

     schema:Emailable
         a rdfs:Class ;
         :property [
             :predicate schema:email ;
             :valueType xsd:string ;
             :pattern "someRegex" ;
         ] ;

     schema:Person
         a rdfs:Class ;
         rdfs:subClassOf schema:Emailable .   # = domainIncludes

     schema:W3CPerson
         a rdfs:Class ;
         rdfs:subClassOf schema:Person ;
         :property [
             :predicate schema:email ;
             :pattern "W3Cregex" ;
         ] .

which inherits the property and its constraints. If you compare those 
two approaches you will see that Option 2 only requires a single, 
consistent mechanism for resolving constraints: walking up the class 
hierarchy, while Option 1 would require looking at two different things 
- local and global constraints. These two mechanisms would have to 
implemented, explained and understood.

Equally important: no other mainstream technology uses global properties 
- OO and XML have local attributes, fields, properties and that's what 
most people are familiar with. This also means its easier to move back 
and forth between those worlds.

In which cases would solution 2 not work?

Holger