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

Pat,

Maybe I have misunderstood something about proposal S.

My understanding was that:
(a) all literals just denote strings (same as your "mental dump")
(b) specific properties are used to relate strings to value-denoting nodes 
for which they are a textual representation.

Where it seems I took a different view was that the (b) properties were 
just some arbitrary vocabulary that reflected the relationship.  I assume 
that some such vocabulary would be defined for the XML schema datatypes, 
but not necessarily using the XML schema datatype URIs themselves, and not 
necessarily a part of core RDF (regarding XML schema datatypes role as 
first among equals rather than having a privileged position in the scheme 
of things).

[...]
>>     ex:foo ex:property "10" .
>>     ex:property rdfs:range xsd:integer .
>>     ex:foo s:property _:a .
>>     _:a s:inDecimal "10" .
>>
>>where it is the node labeled _:a that denotes the integer value 10. (This 
>>entails the smaller example above, right?)
>>
>>I think it *can* be legimitate if the xsd:... URIs are considered to be 
>>RDF class names whose value space is strings that conform to the 
>>corresponding xsd:... lexical space.  In this interpretation, the xsd:... 
>>URIs would not be used to label properties;  some other label would be 
>>required for that (s:property and s:inDecimal in the above example).
>
>OK, but than that is yet *another* suggestion, which we should maybe call 
>G, which is somewhat like the DC suggestion. My problem with G is, what 
>establishes the connection between the lexical class xsd:integer and the 
>'connecting' property s:inDecimal ?

What establishes the relationship between the property and the class is a 
specific interpretation for the vocabulary concerned -- an appeal to 
authority not defined by or within RDF.

For the above example, I had assumed a definition of ex:property that 
licences some additional inferences:

     aaa ex:property "10"
-->
     aaa s:property _:a .
     _:a s:inDecimal "10" .
and
     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've changed the names here to avoid specific xsd: forms.)

I though Sergey was suggesting that this kind of inference would be 
possible.  The basic idiom is not changed, and the additional inferences 
described here provide a migration path from a more naive idiom through 
provision of some additional definitions for each "naive" property used.

..

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;  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.  But I don't think that it's 
unreasonable if the datatyping idiom requires that some additional 
vocabulary be defined;  suppose:

     xsd:integer   denotes an RDF class for the value space of XML schema 
integers

then why not also define:

     xsd-lexical:integer  to denote the lexical space, and
     xsd-mapping:integer  to define the relationship, such that:

     ex:number10 xsd-mapping:integer "10" .
and
     xsd-mapping:integer rdfs:domain xsd:integer .      (as defined above)
     xsd-mapping:integer rdfs:range xsd-lexical:integer .
     xsd-lexical:integer rdfs:subClassOf rdfs:Literal . (or string, or 
something)

..

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.

#g
--

At 01:37 PM 11/20/01 -0600, Pat Hayes wrote:
>>At 12:41 PM 11/16/01 -0600, Pat Hayes wrote:
>>>>I'd like to consider a simple example:
>>>>
>>>>     ex:foo ex:property "10" .
>>>>     ex:property rdfs:range xsd:integer .
>>>>
>>>>Can this be legitimate?
>>>
>>>In S, I don't think so, since xsd:integer has to be a property rather 
>>>than a class.
>>>
>>>Even if we allow it to be used in both ways at once, I cannot see any 
>>>way in which range information on the asserting property (ie the 
>>>property that occurs in the triple which has the bNode as object in the 
>>>S idiom) can possibly constrain the datatype used in the second triple 
>>>(the one that has the bNode as subject and the literal as object.), or 
>>>indeed even have any interaction with it. The triple
>>>_:x xsd:integer "10" .
>>>can be, at best, only constrained to be false by a class restriction of 
>>>the form
>>>_:x rdf:type <someClass> .
>>>It cannot be forced to be true.
>>
>>I think I didn't state my query clearly enough.  The above example is 
>>exactly the case I wanted to test (because I think it corresponds to some 
>>current usage).  But I was not clear that the xsd:integer is *not* 
>>intended to be the property used in the S scheme to indicate an integer value.
>>
>>Consider this slightly enlarged example:
>>
>>     ex:foo ex:property "10" .
>>     ex:property rdfs:range xsd:integer .
>>     ex:foo s:property _:a .
>>     _:a s:inDecimal "10" .
>>
>>where it is the node labeled _:a that denotes the integer value 10. (This 
>>entails the smaller example above, right?)
>>
>>I think it *can* be legimitate if the xsd:... URIs are considered to be 
>>RDF class names whose value space is strings that conform to the 
>>corresponding xsd:... lexical space.  In this interpretation, the xsd:... 
>>URIs would not be used to label properties;  some other label would be 
>>required for that (s:property and s:inDecimal in the above example).
>
>OK, but than that is yet *another* suggestion, which we should maybe call 
>G, which is somewhat like the DC suggestion. My problem with G is, what 
>establishes the connection between the lexical class xsd:integer and the 
>'connecting' property s:inDecimal ?
>
>>
>>>>  If so, what can we say about it?
>>>>
>>>>Could we, for example, allow rdf:type values like xsd:integer to be 
>>>>subclasses of rdfs:literal, so that the members of the value space are 
>>>>still just strings, but having a restricted lexical form?
>>>
>>>But that would not specify the datatype, since "10" might be a decimal 
>>>or a binary or an octal or whatever.
>>
>>I agree that it wouldn't specify the datatype of the value denoted by 
>>intermediate node (_:a in the example above, or _:int10node in the 
>>example below).  I don't see that as a problem.
>
>I do, since there is no way to specify that type, it seems. Since you are 
>using xsd:integer to refer to the *lexical* space of the datatype, there 
>is no name available for the value space; and, worse, the usual usage is 
>that the datatype name refers to the value space rather than the lexical 
>space, so this idiom doesn't conform to accepted usage either.
>
>(In haste)
>
>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

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/

Received on Wednesday, 21 November 2001 09:45:00 UTC