W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2001

Datatyping goals (was: Action 2001-11-16#9 (datatypes))

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Sat, 08 Dec 2001 16:01:16 +0000
Message-Id: <5.1.0.14.2.20011208153653.03488da0@joy.songbird.com>
To: fmanola@mitre.org
Cc: RDF core WG <w3c-rdfcore-wg@w3.org>
At 02:07 PM 12/6/01 -0500, Frank Manola wrote:
>Example requirements:
[...]

Good plan.  Here is my response to the datatyping goals you set out, in the 
form of my reflection and commentary on what I think you are 
suggesting.  I've added one additional goal.

1. Backward compatibility:
    (a) with existing RDF data
    (b) with existing RDF code
    (c) with existing RDF-based specifications

2. Provides an account for using XML schema datatypes with RDF (this being 
a charter requirement).
    (a) where XML schema datatypes are used per XML schema specification 
with RDF/XML
    (b) to use XML-schema defined datatypes with the RDF abstract syntax

??? do we need to account for use of the full range of XML schema 
structured datatypes?

3. Consistency with anticipated DAML+OIL usage.

4. Also provide an account for the use of datatypes other than those from 
XML schema.  These should be handled by the same constructs as XML schema 
datatypes.

??? I don't think we should be getting into processing models here that 
describe who performs the processing, and how.  I think that's an 
implementation issue.

5, 6. It should be possible to describe literal datatyping information with 
associated RDF schema statements (e.g. property ranges and domains), as 
well as directly applied rdf:type statements.  (And possible other means?)

??? I'm not sure what are the actual goals you are trying to capture here, 
particularly the "represent without schema".  The above is the closest I 
can get.

7. Datatypes are not a built-in part of the RDF core, so different 
applications are free to use any appropriate datatypes wherever 
specified.  XML schema datatypes are encouraged as the preferred option for 
W3C specifications, so a specific account is required for these.

8. Broad consistency with the specified model theory.  Any proposal that 
cannot be explained using the current model theory must include the 
necessary model theory developments.

#g
--


At 02:07 PM 12/6/01 -0500, Frank Manola wrote:
>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

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
       __
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
\/___________/
Received on Saturday, 8 December 2001 13:12:30 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:43:01 EDT