Re: DATATYPING: second draft

Patrick.Stickler@nokia.com wrote:
> 
> > -----Original Message-----
> > From: ext Sergey Melnik [mailto:melnik@db.stanford.edu]
> > Sent: 10 December, 2001 15:58
> > To: w3c-rdfcore-wg@w3.org
> > Subject: DATATYPING: second draft
> >
> >
> > I restructured and extended the datatyping document to
> > include the most
> > recent contributions by Graham, DanC, PatrickS and Frank:
> >
> >   http://www-db.stanford.edu/~melnik/rdf/datatyping/
> >
> > New stuff:
> >
> > - notion of datatyping scheme
> > - vocabulary for datatype components: xsd:int.map, xsd:int.val etc.
> > - extended examples of relating datatype components using RDF Schema
> > - completed example for xsd:base64Binary
> > - introduced Idioms A and B
> >
> > Let me know what you think...
> >
> > -- Sergey
> 
> Patrick's Comments:
> 
> 1. Numbered sections would greatly facilitate referencing for comments ;-)

Done, finally! Sorry I pushed this as far out as I could, since I don't
like renumbering sections manually...

> 2. Scope, is it true that we also are not tasked with creating or adopting
> mechanisms for defining data types -- only for capturing data type knowledge
> about literals?

My guess is that we need to explain how to define datatypes
axiomatically (i.e., define the datatype mappings in the model-theoretic
interpretations etc.). Without it, we cannot really talk about using
datatypes. I guess this can be considered as a "mechanism" for defining
datatypes. However, I wanted to stress that we are not chartered with
defining any vocabulary or languages. Do you think additional
clarification is needed?

> 3. Desiderata for RDF Datatyping, bullet item 2, we're only talking about
> simple data types here, right? After all, what does XML Schema have to
> say about complex RDF structures? The only intersection that I see between
> XML Schema and RDF structural models is lexically defined literals/data
> content
> as property values. We perhaps should make it clear that we are not
> intending
> XML Schema to define/constrain/interpret RDF graph structures.

Right. I changed
  Ability to use XML Schema datatypes
to
  Ability to use built-in atomic XML Schema datatypes 

and I also added

  XML Schema is not intended to be used for defining/constraining
RDF/XML syntax or
  RDF graph structures for the purposes of datatyping.

Is this fine?

> 4. Type System, Datatype Mapping, para 4, @@@, I would argue that there need
> not be a lexical representation for every value -- as this would preclude
> being able to define "upper level" data types which serve as a means for
> relating the value spaces of lexically grounded data types (for defining
> intersections of value spaces only, where lexical spaces are incompatible).

Could you give an example?

> 5. Datatyping Schemes, we may wish to make clearer what we mean by
> "represent".
> I assert that for values, we merely denote or uniquely identify the value,
> but provide no actual representation for it in the graph -- otherwise, RDF
> would have to have a built-in canonical representation for all values of
> all data types that would be described in RDF. It is one thing to say
> that ("10",xsd:integer) uniquely denotes the integer value ten, based on the
> definition of datatype mapping, and quite another thing to have the actual
> integer value ten in the graph itself.

point taken. I replaced

  are represented in RDF graphs and interpreted using model-theoretic
semantics. 
by
  are represented in RDF graphs (using one or several resources,
literals, and statements),
  and interpreted using model-theoretic semantics. 

Is this clarification sufficient?
 
> 6. Datatyping scheme "S", I've given my comments already with regards to
> this scheme so I won't repeat them here, other than:
> 
> I view the S scheme as defining a pairing of lexical form (literal) with
> data type (URI) and it is that pairing that "names" the mapping from the
> member of the lexical space to the member of the value space of that
> data type. This concept of pairing is IMO the common intersection between
> all of the datatyping schemes -- and setting aside issues such as which
> node denotes the actual value (if any) or whether literals are strings
> or scalars, etc. they all appear to me as synonymous idioms which all
> serve to define these pairings of lexical form and data type, from
> which the single unique mapping can be inferred. And from that viewpoint,
> it is simply a matter of which idiom(s) are the most optimal, intuitive,
> efficient, and clear. While we should certainly "bless" specific idioms
> to improve interoperability and portability, we may very well define
> the data typing solution similarly to parseType and allow any idioms
> which define these pairings, leaving users/vendors to choose which they
> prefer. The key is simply getting to those pairings. Everything else
> IMO falls out from that.

In my understanding, the abstract conceptualization of datatyping is
quite well introduced in the XSD document. Or do you think it is not?
What would you like to see in its place? In Sec 2, I tried to fill the
remaining gaps in the XSD type system by defining the concept of a
datatype mapping. If you have some alternative mathematical abstraction
for datatypes in mind, please share...

> 7. It would perhaps be useful to extract all of the discussion about the
> specific schemes from this document until we are absolutely agreed upon
> what it is we want/need to capture, and include the various scheme's
> descriptions by reference.

This may make sense depending on the size of the document and the
normative status of its parts.

> This is what I meant in my comments to Frank's
> set of requirements that we should first focus on the abstraction of
> data types before we look at the idioms used to capture data typing
> in the graph. The data typing "model" adopted by RDF should be independent
> of idiom. And we should be free to add idioms later as we need. This is
> why I keep stressing the concept of a pairing as the basis of data typing
> in RDF. It is both free from needing to provide an explicit representation
> of the value, which would be necessary to define the actual mapping, yet
> unambiguously identifies that mapping and thus captures all the knowledge
> that an application needs. Idioms are secondary to that core concept of
> the pairing itself, and we need at least two idioms to handle global and
> local typing.

I agree with all of the above. This is what Sec 2 is supposed to be
about.

> 
> Cheers,
> 
> Patrick

Thanks for your comments!
Sergey

Received on Friday, 14 December 2001 13:50:50 UTC