Re: rdfs:subClassOf and XSD derivation by restriction

On 3/6/18 8:57 AM, Richard Smith wrote:

[...]
>
> 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.

rdfs:subClassOf is a relationship between classes, whose meaning is tied 
up with the extension of the classes. rdfs:subClassOf has nothing to say 
about the lexical-to-value mapping of a datatype.

There is no way in RDFS to state anything about the lexical-to-value 
mappings of two datatypes.  You can't even infer that the image of the 
lexical-to-value mapping of a datatype D1 that is a subclass of a 
datatype D2 is a subset of the image of the lexical-to-value mapping of 
D2.  You can't even infer that the images have a non-empty intersection 
even if the value spaces of both datatypes are non-empty.  (If the value 
space of D2 is a singleton set or is empty, then you can make some 
inferences.)
>
>> 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.

That can't happen.  Stating xsd:integer rdfs:subClassOf xsd:decimal is 
safe, provided that xsd:integer and xsd:decimal are recognized 
datatypes.  There is no way to add something to RDF that is 
contradicatory to any of the consequences of this statements (again 
provided that xsd:integer and xsd:decimal are recognized datatypes).
>
>> 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?

The incompatability will be limited to queries that ask about subclass 
relationships between datatypes.  One semantic extension might say that 
there are subclass relationships (e.g., xsd:int rdfs:subClass 
xsd:decimal) while another might no.
>
> 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.

Replacing datatypes in literals is a different concern.   It is entirely 
possible to have datatypes in a superclass relationship where the 
literal-to-value mappings are not compatible.   Consider, for example 
datatypes like those in programming languages where 1 is (only) an 
integer and 1.0 is (only) a float.   Further suppose that this set of 
datatypes had float values be real numbers, so that the integer datatype 
values are a subset of the float datatype values. So one could have RDF 
datatypes p:int and p:float with p:int rdfs:subClassof p:float where 
"1"^^p:int is the integer 1, but "1"^^p:float is nonsensical.  These 
datatypes would violate my intuitive expectations of RDF datatypes, but 
they are not excluded from RDF.

>
> Richard

peter

Received on Tuesday, 6 March 2018 21:52:34 UTC