Re: Answer to the question: What is a "value" to RDF

>      ex:property rdfs:range lexicalspace:integer .
>      s:property rdfs:range valuespace:integer .
>      s:inDecimal rdfs:domain valuespace:integer .
>      s:inDecimal rdfs:range lexicalspace:integer .

I don't see how 

     aaa s:property _:a .
     _:a s:inDecimal "10" .
     s:property rdfs:range valuespace:integer .
     s:inDecimal rdfs:domain valuespace:integer .
     s:inDecimal rdfs:range lexicalspace:integer .

is better (i.e. less "naive") than

     aaa s:property _:a .
     _:a rdf:value "10" .
     _:a rdf:type xsd:integer .
     s:property rdfs:range xsd:integer .

This also raises the question of the relation between
typed literals versus other typed resources which are
not literals. It appears to me that the S proposal asks
us to treat them differently. I.e. the idiom immediately
above is also analogous to that used for non-literal
typed resources. E.g.

     aaa t:property <urn:foo:bar> .
     <urn:foo:bar> rdf:type foo:KindOfThing .
     t:property rdfs:range foo:KindOfThing .

The only differences between the literal resource and the
non-literal resource is that for the literal (a) we have
to use an anonymous node, since it has no uriref, and (b)
we have to associate the lexical form with the value
node. Otherwise, the treatment is exactly the same. 

The S proposal would ask us to use an entirely different
method of typing literal resources that is incompatible with
the typing of non-literal resources; which doesn't seem
right to me. Or should we also be typing all resources as

     aaa t:property _:b .
     _:b foo:KindOfThing <urn:foo:bar> .

???

> A note on the idiom:  I think would find it confusing if the 
> actual XML 
> schema datatype URI were to be used as an RDF property;  

I agree.

I've also not seen any reply yet to my questions about
what the following might mean in practice:

   aaa ex:age "10" .
   ex:age rdfs:subPropertyOf xsd:integer .

I.e., is the intermediate anonymous node manditory? And if
so, how do we define these new restrictions on the use of
rdfs:subPropertyOf which would prevent expressions such as
the above?


> as 
> you say, it's 
> more intuitive if it represents the value space, so my 
> suggestion of it 
> being the lexical space is also slightly off.  

Yet XML Schema datatype URIs denote both the value space
and the lexical space. How can we say it only represents
one or the other? It represents both. The URI for the
XML Schema 'integer' type represents both the lexical
space that a literal should be a member of as well as
the value space having some member to which the lexical 
form should correspond. It's both, not one or the other,
so you shouldn't use it to represent only one or the other.

Data type classes which have non-literal members only
define a value space. Data type classes which have literal
members denote both the lexical space and value space. 

Right?

> But I don't 
> think that it's 
> unreasonable if the datatyping idiom requires that some additional 
> vocabulary be defined;  

It's unreasonable if its unnecessary, right?

>  ...
> I guess what I'm trying to suggest is using schema S as the preferred 
> idiom, and introducing some elements of scheme DC to handle 
> migration from 
> naively defined properties.

By modifying the DC proposal slightly to utilize the vocabulary
suggested by DAML and provided by the current mapping from RDF/XML
to the graph model, i.e replacing rdf:label with rdf:value:

     aaa s:property _:a .
     _:a rdf:value "10" .
     _:a rdf:type xsd:integer .

then we have all that we need for data typing of literals. 

This idiom is no more "naive" than the S proposal, and is
a far more economical (not to mention currently used) solution. 

It fully denotes the pairing of lexical form to data type, and 
unambiguously denotes the value by the object node of the triple. 

The data type itself defines the value space and (if a literal
data type) also the lexical space and the mapping from lexical space
to value space. RDF should only concern itself with providing 
the knowledge about the pairing of data type and resource, 
whether that resource is denoted by a lexical form or URI Ref;
and the same treatment should be used for both literal and non-literal
resource typing.

Regards,

Patrick

Received on Thursday, 22 November 2001 03:09:49 UTC