- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Sat, 9 Feb 2002 00:08:27 +0200
- To: RDF Core <w3c-rdfcore-wg@w3.org>
- Cc: patrick.stickler@nokia.com
I am very grateful to Pat for his execellent summary of the convergence proposal in terms of his proposed MT treatment and to Jeremy for his earlier distillation of it into specific issues. I feel that within these can be found an excellent solution to the datatyping issue. The following (hopefully) explains why I feel it is in the users' best interest to adopt the convergence proposal without the datatype triple idiom detailed in section 3 of Pat's summary (which actually was not included in the original convergence proposal specifically for the reasons outlined below). I've tried to be relatively terse, which I think will be appreciated. If any particular statement is not clear, just ask and I will gladly expound upon it until it is clear or until you start throwing heavy objects ;-) As with my convergence proposal, please read the whole thing before responding/reacting to a single particular statement, as most are qualified/explained in subsequent paragraphs. OK, here goes... 1. The datatype triple idiom is not needed, and has no actual utility. a) The idiom does not do anything that doublet idiom does not do, except allow multiple types to be explicitly defined for same bNode, yet: b) The ability to define multiple types for same bNode will, I think, rarely be useful even even more rarely used, and: c) The utility of such multiple type definition is an illusion since it doesn't remove any untidyness in value comparisons because doublet and global idioms still exist, and also there may be separate datatype triples which denote same value. Thus, the datatype triple idiom actually does not offer any real utility. 2. The inclusion of the idiom does not meet the "KISS" desire of users. a) Since not needed, it merely adds complexity both for users and implementors. The point of a standard such as RDF is to provide a consistent, explicit point of intersection between knowledge producers, knowledge consumers, and application implementors which facilitates efficient implementation and interoperability. Including needless components for the sake of style or preference which impact portability of knowledge and interoperability of systems, or needlessly complicate implementation or use of such knowledge are contrary the very point of such a standard. b) It is not as symmetrical with the global idiom, therefore harder for users to understand its relationship with the global idiom than is the doublet idiom. RDF is already widely percieved as "difficult to understand" and "difficult to use". The last thing we want to do is make it any more difficult by making the datatyping solution needlessly complicated. We have an opportunity to provide a solution based on two clearly and intuitively related idioms which help users understand the relation between typed literals and the datatype that provides the context for that typing. The superfluous, more complex datatype triple idiom undermines us providing the simpler, fully symmetrical solution. c) It requires schema definitions to use -- and thus it is not a schema-free local idiom, which was the whole point of providing a local/explicit idiom. One must define each datatype as an rdfs:subPropertyOf rdf:value in order for the MT interpretation to work. Thus, the idiom does not meet the desiderada of either a local/explicit or global/implicit idiom, but is a kind of strange hybrid that needs both local definition and schema definition to work. 3. The idiom forces the qname issue. The XML Schema community strongly dispute RDF qname practice as valid and an idiom that requires the use of qnames puts us deep in the middle of that issue -- which likely cannot be resolved within the boundries of our present charter. One has no choice but to use qnames to use the datatype triple idiom, whereas the other idioms work with full URIs and avoid this issue entirely. Why exacerbate this issue needlessly? 4. Its interactions with rdfs:subPropertyOf are not clear. a) Datatype properties only make sense with a bNode domain. We must either somehow restrict the use of datatype properties to bNode subjects or explain to users why they should do that, making more work for us and more for users to understand. If not restricted in this fashion, then: b) What does it mean to combine datatype semantics with "traditional" property semantics? If some property such as ex:age is declared as a subproperty of xsd:integer, what does that mean? Should it even be allowed (per (a) above)? Should users be advised against it, and why/how? Again, more questions to be answered and addressed by the MT, the primer, the spec, or elsewhere. c) Cohabitation with doublet and global idioms not yet certain. See my comments in my reply to Pat's summary which detials a potential erroneous inference based on combined use of all three idioms (sorry, offline, but should be easy to find). Even if the MT could be re-re-re-vamped to address these issues, that's unnecessary work, since we have a local idiom (which is a true local idiom not requiring any schema assertions to be properly interpreted) and the single percieved benefit of the datatype triple idiom is, as explained above, an illusion; so what's the point in continuing to try to make the idiom work (apart from just stylistic preference)? -- Thus, the combined weight of all of these issues regarding the datatype triple idiom is, I feel, overwhelming, and we will be serving RDF users far better by giving them a solution based only on the symmetrical doublet and global idioms. If we take the original convergence proposal and Pat's MT for it, sans the datatype triple idiom, then we can be done with datatyping. I repeat, done. Whoohoo! Please, please, please, let's drop this extra idiom and move on. OK? RDF users, both present and future, will thank us. Really. Cheers, Patrick
Received on Friday, 8 February 2002 17:07:15 UTC