- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Wed, 21 Nov 2001 14:05:13 +0000
- To: Pat Hayes <phayes@ai.uwf.edu>
- Cc: w3c-rdfcore-wg@w3.org
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