Re: heading toward datatyping telecon

A few musings, to borrow Graham's term.

As I understand Pat's proposal, the main idea requires literals to be subjects. 
   Now, RDF/XML doesn't allow us to represent literals as subjects and we have 
decided that extending it is out of charter.  However, in Pat's proposal bnodes 
can match literals as well as resources, so we could use bnodes for now and 
extend later.  Yes?  If so we can focus our discussions now on the bnode 
representations.

Pat's proposal defines a type to be a mapping from a lexical space to a value 
space.  That means that a hexadecimal integer is a different type from a decimal 
integer.  That's going to be confusing to programmers.  I suppose we could 
define integer to be a super-class of hexadecimal integer and decimal interger, 
i.e. for each value space define a class that all types mapping to that value 
space are subclasses of.

Still somehow that does not sit right with my intuitions.  In rdf schema I want 
to  say that the value of a property is an integer; after parsing I don't much 
care whether is was represented in decimal, binary or hieroglyphics.  rdf schema 
is about describing the data model, not the syntactic representation.

How would I write a schema that would allow the value of a property to be either 
a decimal or a hexadecimal integer?

How do the different approaches handle merging of graphs, as in:

Consider RDF/XML serializations of two graphs each describing 
http://example/thingy.  Each has an eg:size property for http://example/thingy. 
  In one graph the size is represented by a decimal integer "12".  In the other 
the size is represented by the hexadecimal integer "C".

How would software, knowing that http://example/thingy has only one size 
property, merge the graphs given the different approaches.

Brian


Sergey Melnik wrote:

> Folks (esp. Pat),
> 
> I'd like to keep the fruitful momentum around datatyping. If you
> remember,
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0530.html
> contained three suggestions on how to proceed with datatyping. In my
> understanding, the bottom line of the recent discussion on the topic
> is the following.
> 
> <SUG1> (what specs to use) was critized because UML is a large spec to
> get into. I don't think <SUG1> is something we have to vote on. "Using
> a spec as a foundation" does not sound normative anyway. However, I
> think the datatyping discussion needs some well-defined deliverables.
> One of them could be to specify how XML Datatypes (at least the
> primitive ones) should (or SHOULD) be used in RDF. I'd like to suggest
> that we vote on this deliverable next Friday.
> 
> <SUG2> was to focus on representing typing info in the triple
> structure. To my knowledge, there haven't been any public objections
> so far. Several schemes discussed on the list recently were in synch
> with SUG2. It seems that we are already going down the SUG2 path, so
> maybe voting is not even necessary - but it would be nice to do so for
> the record.
> 
> <SUG3> was to make the interpretation of each literal symbol fixed and
> determined by its textual contents. Pat and Peter P.-S. (who provided
> valuable input as a non-member) propose a different approach, in which
> the meaning of literal symbols depends on the context where they
> appear (this context may be limited to a single statement, I'm not
> sure about that). To my knowledge, Pat is still working on a new draft
> of MT that relies on such context-dependent interpretation of
> literals.
> 
> I'd like to ask Pat to try to wrap up some ideas (even if sketchy) and
> share them with the WG in form of examples and illustrations. We
> should attempt to achieve a common understanding of the options that
> are open at this point. Datatyping is critical in the sense that
> almost every single developer will need to deal with it. Therefore, it
> is essential that even persons who are far from logics and model
> theory (like some of us) understand the main points.
> 
> In any case, tomorrow I'm going to summarize my revised understanding
> of the tradeoffs between a `straightforward' and Pat's/Peter's
> approach.
> 
> Sergey
> 
>

Received on Thursday, 1 November 2001 17:32:52 UTC