W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

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

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 20 Nov 2001 14:25:36 -0600
Message-Id: <p0510100ab8206b771e75@[]>
To: Patrick.Stickler@nokia.com
Cc: Graham.Klyne@MIMEsweeper.com, w3c-rdfcore-wg@w3.org
>  > -----Original Message-----
>  > From: ext Graham Klyne [mailto:Graham.Klyne@MIMEsweeper.com]
>>  Sent: 17 November, 2001 18:57
>>  To: Pat Hayes
>>  Cc: w3c-rdfcore-wg@w3.org
>>  Subject: Re: Answer to the question: What is a "value" to RDF
>>  Importance: Low
>>  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).
>This is the interpretation that is suggested in my
>recent recommendation
>In a nutshell, it is the "object slot" of the statement
>that denotes the value, not the "thing" that is in the
>slot (literal, uriref, or bNode).

1. That isn't a new interpretation; all the proposals that require 
the MT extension (P and P++ of those on the table, and possibly X) 
all assume that the graph node itself is the primary denoting entity. 
They have to, since the same literal label might have different 
meanings in different contexts. That is why they require that RDF 
graphs not be restricted to be tidy on literal nodes.

2. That isn't what Graham is talking about here (I think).

>  > [Later]
>  >
>>  It also occurs to me that we could have three parallel
>>  namespaces; e.g.
>>      xsd:integer a rdf:Class.     (Lexical space of decimal
>>  integers, per
>>  XML schema)
>>      xsdv:integer a rdf:Class.    (Value space of integers,
>>  per XML schema)
>>      xsdp:integer a rdf:Property.
>And precisely who is the authority defining these classes
>which have meaning only to RDF

Obviously, the RDF Core WG. It's our language, and we can say what it means.

>, and how does that sync up
>with the use of XML Schema simple class usage outside of
>RDF, and does that mean that *every* data type scheme must
>define three parallel taxonomies?
>This is what I mean by the S proposal not being fully
>understood as far as implications to the big picture.

The S proposal does not involve the introduction of new vocabulary in this way.


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 20 November 2001 15:25:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC