- From: Frank Manola <fmanola@mitre.org>
- Date: Thu, 06 Dec 2001 14:07:13 -0500
- To: RDF core WG <w3c-rdfcore-wg@w3.org>
> Action 2001-11-16#9 FrankM Clarify the architectural and other broader > concerns with any datatyping scheme that must be considered. As usual, the action recorded in the minutes sounds much grander and well-thought-out than what I actually had in mind when I raised the issue (thanks to charitable interpretation by the scribe!) Anyway, what I was getting at was that, in the ongoing datatype discussion, what with all the discussion about the details of how the various proposals worked, what things in those proposals denoted, and so on, I was afraid we were losing track of what requirements we were trying to support. We need to be able to keep straight, in discussing the various approaches, whether we are (for example) disagreeing about the requirements, or disagreeing about how to support them (or both, or neither). This isn't to say there hasn't been discussion of requirements, and a number of the submissions have described individual requirements, or lists of them, but I'd like to see more discussion (perhaps in parallel with what's going on now) specifically targeting requirements, and determining what priority to give to them. Here's a list of the sorts of requirements I have in mind (in no particular order). Most, if not all, of them have been cited in earlier postings. In some cases, these requirements may overlap or are contradictory. I meant (and still do mean) to develop this theme further, but I thought I'd get this much out now. --Frank Example requirements: 1. backward compatibility with existing RDF data and applications usage 2. works with XML Schema data types (or, at least, doesn't preclude using them) [In considering this requirement, consider both the case where we're processing RDF/XML containing uses of XML Schema data types, and the case where we're processing triples. Are there differences?] 3. compatibility (or at least non-interference) with the current DAML+OIL approach to datatypes 4. ability to use non-XML-Schema datatypes (custom or user-defined datatypes, or those from major components external to RDF, like SQL or UML datatypes) [The idea here is that I should be able to indicate that I'm using datatypes from a given datatype scheme by citing its URI, and handoff datatype-specific processing at appropriate points to a processor that is associated with that scheme. If XML Schema datatypes are handled in RDF without building them into RDFS processors (presumably by appropriately invoking an XML Schema processor), then it ought to be possible to generalize this architecture to allow other processors.] 5. ability to represent type information without an associated schema 6. ability to represent type information in an associate schema 7. ability for an RDF processor to handle typed literals without building the types in ***Others?**** Architectural isues arise in, among other things, thinking about how and where various bits of processing involving data types are going to occur. For example, in http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0448.html, Pat asks: > >(C4) are multiple type assignments allowed? (e.g. US dollar, decimal) > > Better, what happens when they occur? Eg suppose two > sources/documents/whatever supply different such information; which > part of the RDF machinery complains? (the lexical analyzer, the > parser, an inference engine, or some other datatyping module?) So what machinery are we assuming, and how do we assume the various pieces handoff information to each other? -- Frank Manola The MITRE Corporation 202 Burlington Road, MS A345 Bedford, MA 01730-1420 mailto:fmanola@mitre.org voice: 781-271-8147 FAX: 781-271-8752
Received on Thursday, 6 December 2001 14:07:49 UTC