RE: Action 2001-11-16#9 (datatypes)

Great summary Frank. A few comments and clarifications below
(to be sure I'm understanding everything as you intended) ...

> -----Original Message-----
> From: ext Frank Manola [mailto:fmanola@mitre.org]
> Sent: 06 December, 2001 14:07
> To: RDF core WG
> Subject: 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:

Should we follow Pat's original mental dump format by trying to
construct a matrix showing which proposals meet which requirements.
That way, we can perhaps more easily compare the pros/cons of
each proposal insofar as the requirements are concerned.
 
> 1. backward compatibility with existing RDF data and 
> applications usage

We should specifically identify what this means. I.e. specific
idioms, interpretations, etc.

> 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?]

We need to clarify what "works with XML Schema data types" means. I.e.
a) only simple data types
b) simple and complex data types (though I don't see how the latter is
   really possible)
c) only referencing data type URIs
d) employing XML Schema mechanisms/vocabulary
e) ...

> 3. compatibility (or at least non-interference) with the current
> DAML+OIL approach to datatypes

Should this be a sub-requirement/component of #1 above?

> 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.]

This would likely suggest an interpretation of #2, such that, if we
must support non-XML Schema data types (which I take as imperative)
then this would seem to preclude an interpretation #2(d).

> 5. ability to represent type information without an associated schema

I take this to mean "local typing". I.e. type is associated with the
object node in the graph by some idiom (DAML/DC/U/...). Right?

> 6. ability to represent type information in an associate schema

I take this to mean "global typing". I.e. the use of rdfs:range
or similar mechanisms. And by "schema" you mean RDF schema not
XML schema.

> 7. ability for an RDF processor to handle typed literals without
> building the types in

This is likely related to #2 and #4 as to how generic "open" support 
for data typing schemes is provided.

> ***Others?****

There should be a single conceptual model of data typing that is not tied
to a specific idiom, and if multiple idioms are adopted then they
should be defined as synonyms for this underlying model. We should
not adopt multiple idioms which are based on different models, even
if one can define the relations between the models and map between
them.

> 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?

Is this basically the issue of validation? I.e. which layer tests
that some lexical form is a member of the lexical space of a data
type and if multiple data types are specified, that the values
denoted constitute the same or analogous values. Where are lexical
errors or contradictions trapped. Right?

Cheers,

Patrick

Received on Monday, 10 December 2001 21:29:43 UTC