W3C home > Mailing lists > Public > semantic-web@w3.org > March 2018

Re: rdfs:subClassOf and XSD derivation by restriction

From: Richard Smith <richard@ex-parrot.com>
Date: Tue, 6 Mar 2018 15:57:32 +0000 (GMT)
To: "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
cc: semantic-web@w3.org
Message-ID: <alpine.LRH.2.02.1803041535250.9860@sphinx.mythic-beasts.com>
Peter F. Patel-Schneider wrote:

> You are correct that RDFS subclass inferencing wrt instances is one way only, 
> i.e., if C rdfs:subClassOf D then instances of C are also instances of D but 
> if all instances of C are also instances of D then it is not necessarily the 
> case that C rdfs:subClassOf D.

Thanks for that (and sorry not to acknowledge it sooner).

I received another reply (not copied to the list) saying 
exactly the opposite, i.e. that it is true by definition 
that C rdfs:subClassOf D in this case.  I think I can 
trivially demonstrate why this should not be the case. 
Suppose I have two subclasses of xsd:decimal called 
ex:heightInFeet and ex:heightInMetres, both the with same 
lexical and value spaces.  I'm not sure this would be good 
practice, but I'm pretty sure it's not wrong.  This means 
all instances of ex:heightInFeet are also instances of 
ex:heightInMetres, and vice versa.  If this argument were 
valid, this would make each a subclass of the other, which 
is clearly not desirable.

> So what subclass relationships can be inferred in RDFS?  This is specified in 
> https://www.w3.org/TR/rdf11-mt/#rdfs-interpretations where you get all 
> classes are subclasses of rdfs:Resource, subclass is reflexive on classes and 
> transitive, datatypes are subclasses of rdfs:Literal, the container classes 
> are subclasses of rdfs:Container, rdfs:ContainerMembershipPropery is a 
> subclass of rdf:Property, and rdfs:Datatype is a subclass of rdfs:Class.  
> That's it.
>
> So even with it being the case that all integers are decimals in XML Schema 
> Datatypes, RDFS does not require that xsd:integer is a subclass of 
> xsd:decimal, even for RDFS processors that recognize both these datatypes.

Okay.  That sounds plausible enough.

To be honest, I'm not absolutely convinced that 
rdfs:subClassOf means what I think with datatypes.  For 
instance, does

   ex:a ex:p "sss"^^ex:sub .
   ex:sub rdfs:subClassOf ex:super .
   ex:super a rdfs:Datatype .

RDFS entail this?

   ex:a ex:p "sss"^^ex:super .

I'd expect it to, but it doesn't.  Maybe that means I don't 
want to be using rdfs:subClassOf at all.

> Of course, there is nothing wrong in adding xsd:integer rdfs:subClassOf 
> xsd:decimal to any of your RDF graphs.  That's not going to infer anything 
> false. 

That's almost exactly my concern.  The graphs I'm interested 
in aren't under a single person's control.  I anticipate a 
user pulling in statements from one or more ontology (one of 
which I control) together with various statements of their 
own, which the gets processed in various ways.

I don't want to get into the question of trust here, so for 
the sake of this discussion let's assume no-one is 
deliberately trying to break or subvert the logic model.

But I am concerned that some seemingly-sensible statement a 
third party might make about xsd:integer or xsd:decimal 
might subtly conflict with me stating an rdfs:subClassOf 
relationship between them.

> It's also not wrong to have an RDFS processor that implements a 
> semantic extension that augments subclass so that X rdfs:subClassOf Y for X 
> and Y recognized datatypes when X is somehow a subdatatype of Y.  Just be 
> aware that this is an extension to RDFS, and, as well, there might be similar 
> but not completely compatible semantic extensions implemented in other RDFS 
> processors.

Again, that's the concern.  How likely is an incompatibility 
in practice?

Or perhaps I should look at this in another way.  Is there 
an existing extension to RDFS that someone else has already 
thought about that provides some sort of meaningful subtype 
relationship for datatypes that allows datatypes to be 
replaced with their supertype in literal?  So far as I can 
see, OWL datatype restrictions don't allow that.

Richard
Received on Tuesday, 6 March 2018 16:00:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 March 2018 16:00:37 UTC