Action 2001-11-16#9 (datatypes)

> 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