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.

It doesn't REQUIRE it, but it sure would be much neater if they could be.

>  Now, RDF/XML doesn't allow us to represent literals as subjects and 
>we have decided that extending it is out of charter.

Well, not all RDF graphs can be represented in RDF/XML, so why is 
that a serious constraint?

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

Not sure I follow this. (What do you mean by 'match' here?)

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

Obviously the datatype mappings are not the same, but the value 
spaces can be overlap or even be the same. We can make them 
rdfs:subclasses of one another if you like.

>That's going to be confusing to programmers.

Really?? I know some programmers who like things very strongly typed 
and want to distinguish integers that happen to be positive from 
positive integers. It all depends on what typing discipline you are 
comfortable with.

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

Right, that would be a 'safe' way to do it for almost everyone.

>Still somehow that does not sit right with my intuitions.

Why not?

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

I agree, but you might want to allow those who feel like doing so, to 
import some distinctions into their data models that to you seem like 
syntactic matters.

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

If that distinction is going to 'do' datatyping (in *any* datatyping 
scheme) then you need to retain it somehow. The safe way would be to 
have three classes: the decimals and hexadecimals, which are datatype 
classes, and the integers, which is a superclass of those two and is 
not a datatype class (because there is no way to know , from knowing 
only that "23" is an integer, whether it means 23 or 19 or even 203.)
This really is reasonable, since there really are no such things as 
decimal *integers*; decimals are (one kind of) *numeral*.

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

In my simplest MT extension, you just merge the graphs. But be 
careful: how is the datatyping information supplied in your two 
graphs? I would need to know in order to answer the question fully.

Pat


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


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 1 November 2001 20:22:14 UTC