- From: <Patrick.Stickler@nokia.com>
- Date: Mon, 26 Aug 2002 16:42:18 +0300
- To: <Patrick.Stickler@nokia.com>, <fmanola@mitre.org>
- Cc: <w3c-rdfcore-wg@w3.org>
> But rdf:type is already allowed to be an attribute. > > Consider the analogous local typing of a URIref denoted resource: > > <ex:friend rdf:type="&ex;Person" rdf:resource="#Bill"/> > > which gives us > > ?s ex:friend <#Bill> . > <#Bill> rdf:type ex:Person . > > How is that any different from the analogous local typing of > a datatype value (resource): > > <ex:age rdf:type="&xsd;integer">10</ex:age> > > ??? > > These look pretty similar to me, both semantically and syntactically. > > So, if using rdf:type as an attribute in this manner is obfuscating, > then RDF is already obfuscated, and using it for local datatyping > does not further obfuscate the syntax. This is just taking an existing > legal form of expression and extending it to work with literals in > addition to URIrefs. > > No? Specifically, taking the following rule for nodeElements as a template: S2 If there is an attribute a in propertyAttr with a.URI = rdf:type then the following statement is added to the model: e.subject.string-value <a.URI> <a.string-value> . then for typed literals we introduce a similar rule for both literalPropertyElt and parseTypeLiteralPropertyElt XX If there is an attribute a in propertyAttr with a.URI = rdf:type then the following statement is added to the model: e.subject.string-value e.predicate.string-value <a.string-value>/o.string-value . or something like that. You get the point. I.e. this isn't really that big a change to the syntax, and rdf:type already is allowed as an attribute. Patrick
Received on Monday, 26 August 2002 09:42:22 UTC