Re: rdfs:domain and rdfs:range

On Sun, 19 Nov 2017 12:21:15 +0100, Jürgen Jakobitsch <juergen.jakobitsch@semantic-web.com> wrote:
> T-BOX:
> y:Rock a rdfs:Class.
> z:Human a rdfs:Class.
> z:BiologicalSex a rdfs:Class.
> z:hasBiologicalSex
>         a owl:ObjectProperty;
>         rdfs:domain z:Human;
>         rdfs:range z:BiologicalSex.

Totally agree that the example didn't make much sense and we can't complain
that we get "wrong" inferences from wrong data.


Sometimes ontology writers mistake rdfs:domain/range" as guidance properties
"type can be" rather than the actual restriction/inference "type must also be".

If that's what you mean, then in RDFS you have to add a new common superclass; or 
in an OWL ontology you can make a "combination" domains/ranges using a unionOf
construct, e.g.:

schema:funder a owl:ObjectProperty;
   rdfs:domain [
     a owl:Class;
     owl:unionOf (schema:Organization schema:Person schema:CreativeWork Schema:Event)
   ] .


However the above is a closed union - no-one can easily extend this with a
class that is not compatible with those listed.


I think that's why schema.org went the other direction and defined their own:

http://schema.org/rangeIncludes
http://schema.org/domainIncludes

Here no "damage" is caused by adding another domainIncludes, although I still
am sceptical about giving rocks biological sex :)


See for instance http://schema.org/funder
which if we run through Gregg's distiller we get:

schema:funder a rdfs:Property;
   rdfs:label "funder"@en;
   schema:domainIncludes 
     schema:Organization,
     schema:Event,
     schema:Person,
     schema:CreativeWork;
   schema:rangeIncludes 
     schema:Organization,
     schema:Person;
   rdfs:comment "A person or organization that supports (sponsors) something through some kind of financial contribution."@en;
   rdfs:subPropertyOf schema:sponsor;
   rdfa:usesVocabulary schema: .


Thus we don't accidentally infer that a person is also an event and organization, 
the domain/range inclusion is just a suggestion that a schema:Person might or
might not have a schema:funder property.


Thus anyone is free to extend the above, e.g.:

   schema:funder schema:domainIncludes ex:Food .

..without accidentally inferring that the food is something between a Person or CreativeWork.


In OWL we can do something similar with property restriction on a class, e.g.:

ex:FreeFood a owl:Class;
  rdfs:subClassOf ex:Food .
  rdfs:subClassOf [
     a owl:Restriction;
     owl:onProperty schema:funder
     owl:minCardinality "1"^^xsd:nonNegativeInteger;
     owl:someValuesFrom owl:Thing;
   ] .
]


This is good for required properties, but this does not tell us that any
ex:Food can have an **optional** funder. One pattern I have observed to document
that:

ex:Food a owl:Class;
   rdfs:subClassOf [
     a owl:Restriction;
     owl:minCardinality "0"^^xsd:nonNegativeInteger;
     owl:onProperty schema:funder
   ] .

(or owl:allValuesFrom owl:Thing, but I think that might be more confusing)


While "minimum 0" is non-sensical from an inference point of view, it is not
wrong, and this hints to humans that 0 (implied: or more) schema:funder can be
on a Person. But again this could be easily misread as "exactly 0 funders"..


You may want to use ShEx or SHACL RDF shapes if you just want to express
schema-like that you expect certain general properties on a specific class.

But I would first suggest the original correspondant uses the two schema.org
variants if they are just doing documentation.



-- 
Stian Soiland-Reyes
The University of Manchester
http://www.esciencelab.org.uk/
http://orcid.org/0000-0001-9842-9718

Received on Monday, 20 November 2017 17:13:30 UTC