Re: Handling multiple rdfs:ranges

As Graham explains, I think many ontologies now use the owl:unionOf
construct to handle mutliple ranges.
And so do tools as Protégé.
 
See for instance the schema.org ontology[1] where mutliple domain/range
are often used. 
Here is an example:
schema:about a rdf:Property;
    rdfs:label "About"@en
( 'mailto:"About"@en') ;
    rdfs:comment "The subject matter of the content."@en
( 'mailto:"The subject matter of the content."@en') ;
    rdfs:domain [ a owl:Class; owl:unionOf (schema:CommunicateAction
schema:CreativeWork) ];
    rdfs:range schema:Thing;
 
The Bioportal  ontology certainly does so as well.
 
Fabian

 
 
[1] http://schema.rdfs.org/
>>> Graham Klyne <gk@ninebynine.org> 23.02.2016 11:35 >>>
On 23/02/2016 09:24, Ross Horne wrote:
> My follow up question is: whether anyone knows whether the more
> accommodating inference, as implied by Bioportal, was ever discussed
during
> the RDFS standardisation process; and if so, why the more
restrictive
> definition for multiple domains and ranges was chosen.
>
> I suspect this question has a simple explanation in model theory,
which is
> why I also copy Pat.
>

I recall this was discussed in the 2000-2004 RDF working group, or at
least 
among some members of the working group at that time.

A concern here is for logical monotonicity - the introduction of new
knowledge 
cannot invalidate existing knowledge, otherwise how can one know for
sure that 
anything you think you know is actually true in a context that invokes

open-world semantics?

There are alternative models (e.g. default reasoning), but in order to
draw firm 
confusions they require assuming that one has a complete set of
assertions (i.e. 
no more can be added).

Also from the 2000-2004 RDF working group (which ran in parallel with
the first 
OWL working group), the RDF list construct (aka
rdf:parseType="Collection") was 
introduced so that (among other things) OWL could make closed
assertions, such 
as owl:unionOf (see 
https://www.w3.org/TR/2004/REC-owl-guide-20040210/#SetOperators).

#g
--

Received on Tuesday, 23 February 2016 10:49:53 UTC