Re: around the table on datatypes [ was: Re: datatyping draft 3 (for telecon)]

>On Mon, 2002-02-18 at 13:34, Brian McBride wrote:
>>  At 23:58 14/02/2002 -0500, Pat Hayes wrote:
>>  >Latest version of the datatype summary document now available at
>>  >
>>  >http://www.coginst.uwf.edu/users/phayes/DatatypeSummary3.html
>>  >
>>  >incorporating ideas arising from discussions with Patrick S. (rdfs:drange
>>  >and especially section 10).
>>
>>  I would like to "go round the table" of the WG on the latest datatype
>>  proposal.  By go round the table, I mean to solicit the views of each
>>  member of the WG, without initiating a debate on members views.  We can
>>  then summarize those views and deal with issues arising.
>>
>>  Please answer the following questions:
>>
>>     o Does the datatyping proposal meet your
>>       needs and the needs of your users?
>>       (Who are they?) (What is missing?)
>
>No. Two things are missing:
>
>(a) enough RDF/XML examples to get going in monkey-see-monkey-do fashion

I agree about that, but could someone else provide them? I don't 
trust my ability to get the XML right.

>(b) S-B, i.e. a way to use rdfs:range to restrict the range
>of a property to the lexical space of some datatype.

OK, let me try to fix this.

I pointed out that the MT conditions require that the range of any 
datatype property is the lexical space, and suggested that one could 
use this device:

ex:integer rdfs:range _:x .
ex:otherProperty rdfs:range _:x .

to make the required connection. Sergey pointed out that this doesn't 
work because the rdfs conditions on rdfs:range only require the 
object to be a superset of the range, not the precise range itself, 
so this pair could be satisfied by a suitably generous _:x and still 
the property ranges have nothing to do with one another,  even though 
the range of the datatype is indeed required to be the lexical space.

(What we really want to be able to say is that the range of 
otherProperty is a subset of the range of ex:integer, but we can't do 
that in RDF as we can't form a class by restricting a property. Or 
else be able to write an universal implication, but we can't do that 
in RDF...)

Sergey suggested introducing rdfs:ExactRange or some such, but I 
don't want to do that for a whole lot of reasons (basically it 
suddenly extends the power of the RDFS in all kinds of other 
directions, allowing it to express negation in unintutive ways, 
etc...). And we want to keep the vocabulary small.

Still, we do need something. So how about using drange to do it. In 
other words, lets make the following extra specification on drange: 
when ddd is a datatype property,

ddd rdfs:drange aaa .

means that (the class extension of) aaa is *precisely* the range of 
ddd, ie precisely the lexical space of the datatype, We already have 
a name for the precise value space of the datatype, so the other end 
is, er, sharp already. Then the pair of shared-bnode triples above 
would work if the first one said drange instead of range.

This means drange exerts an extra kind of semantic magic, but only 
when applied to a datatype property. This doesn't interfere with the 
other magic attached to drange since that only kicks in if the object 
is a datatype class, and that's never going to happen in this case 
(unless there are two datatypes with the lexical class of one being 
the value class of another?? .... Nah, never happens)(And even if it 
did, it wouldn't cause any damage.)  And it doesn't infect the rest 
of RDFS since this magic only applies to lexical spaces of datatypes 
which are just the ones where we really can tell if something is NOT 
in the class in question, so it doesn't sneak negation into RDFS by 
the back door.

Happy with that?  It's a small extra write-up.

Pat

PS  Patrick S, I think you maybe already suggested this??? I didn't 
grok it at the time.


>I think these are straightforward additions; they're as much
>about emphasis and documentation as technical specifics
>(though using rdfs:range this way requires that the model
>theory admit literals as subjects.)

I don't see that it requires it. But actually, now that literals 
nodes are tidy and literals denote themselves unambiguously, there 
really is no reason why we could not allow literals as subjects. It 
would require no changes to Ntriples or anything else. All we need is 
a kind of Neitzschean Will to Declare Truth.

>
>>     o Are there features that could be dropped and
>>       still meet the needs of your users? (Which?)
>
>I could live without doublets (rdf:value/rdf:dtype).
>I don't mind them being there, though.
>
>>     o Does the proposal 'work for you'?
>
>I think so.
>
>I'm not sure I understand the question.

Just say 'Yes' and smile.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Monday, 18 February 2002 18:34:16 UTC