- From: <Patrick.Stickler@nokia.com>
- Date: Thu, 22 Nov 2001 10:09:20 +0200
- To: Graham.Klyne@MIMEsweeper.com, phayes@ai.uwf.edu
- Cc: w3c-rdfcore-wg@w3.org
> 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