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

Re: DATATYPES: mental dump.

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Tue, 13 Nov 2001 20:50:24 -0600
Message-Id: <p05101049b817885454f7@[]>
To: Sergey Melnik <melnik@db.stanford.edu>
Cc: w3c-rdfcore-wg@w3.org
>Pat Hayes wrote:
>>  >Pat,
>>  >
>>  >thanks for a great "dump". I'm going to work it into the document almost
>>  >completely, if you don't mind.
>>  Sure, that's what I wrote it for.
>>  >I'm thinking of a running example that can be used to illustrate the
>>  >different proposals and modeling options.
>>  Good idea.
>>  >My current shot at it is:
>>  >
>>  >http://WWW-DB.Stanford.EDU/~melnik/rdf/datatyping/fig/motivating_example.gif
>>  >
>>  >It shows an interpretation, which can be encoded in many different ways,
>>  >e.g. as:
>>  OK, though I think we need to be careful about having the strings in
>>  the interpretation, since the X and P schemes probably won't have
>>  anything denoting those.
>Right. I understand that strings may still exist somewhere in the
>interpretation even if the corresponding graph does not contain any
>symbols that denote those strings. Is this correct?

Oh yes, sure.

>>  Also, this can be described in several different ways even within a
>>  given datatyping-syntax option, so we need to be careful not to get
>>  confused with alternative ways of describing this structure in RDF.
>I completely agree. There are multiple alternatives per proposal. Maybe
>each of the "authors" could pick one or two that illustrate the idea
>best? Specifically, to present a particular syntax in the most favorable
>way, we could use namespace abbreviations that match the label of the
>proposal. For example,
>>  >_Robby ageMonthDecimal "12"
>>  >_Robby weightKgDecimal "14"
>>  >_Jenny weightKgOctal   "14"
>>  >_Jenny ageYearsDecimal "1"
>could be
>_Robby p++:ageMonth      "12"
>_Robby p++:weightDecimal "14"
>_Jenny p++:weightOctal   "14"
>_Jenny p++:ageYears      "1"
>_Robby ---p++:weightKg--> "14" ---rdf:type--> xsd:decimal
>in P(++) scheme
>_Robby     p:weightKg "14" .
>p:weightKg rdfs:range xsd:decimal .
>in P scheme etc.

Well, I don't like this so much as I think that the various schemes 
can often use the same vocabulary, they just use it slightly 
differently. This makes it seem that p++:xsd:integer would be a 
different beast than s:xsd:integer.

>>  >The advantage of starting with an interpretation instead of a piece of
>>  >syntax is that is it possible to refer to the different entities in the
>>  >domain of discourse directly and tell how the corresponding pieces of
>>  >syntax are mapped onto them (for example, "12" and "1" above are
>>  >interpreted as entity d1 in the figure).
>>  Ah, I see. That seems rather odd to me, I confess, as it assumes that
>>  durations are the value space of a datatyping scheme.
>The example goes a bit farther than just talking about numbers. Age,
>weight, months etc. popped up on the list several times in the context
>of datatyping, and I think it is important to clarify what exactly
>different graphs and syntaxes try to express in each specific example.
>In other words, I feel it is important to distinguish whether the token
>"14" in (_Robby p:weightKg "14") denotes a string, a number, or a mass.

Yes, i agree.

>  > I would have
>>  guessed that it was more likely that numbers - the n1-3 in your
>>  figure - would be in the literal value space, and that things like
>>  inYears and weightKg would be rdf properties.
>In fact, I avoided the term "literals" in the figure on purpose,

Right, in your figure that would have begged far too many questions!

>the literal values may comprise different sets of entities in different
>schemes. Similarly, the extensions like "weight" or "inYears" in the
>diagram must not necessarily be denoted by any properties in either
>scheme, just like P(++) may lack an explicit denotation for strings.
>>  I guess the moral is that part of the 'model' must be what datatyping
>>  schemes are supposed to be in use.
>Do you still think so given the explanations above?

Yes, I do. I think that part of my overall feeling of confusion comes 
from the fact that we don't seem to have a crisp definition of what 
constitutes a datatype or a datatyping scheme (Peter had one, but I 
havn't seen it endorsed by anyone else) and still less, any kind of 
syntax for referring to the things. I would like each author to say 
(1) what they take a datatyping scheme to be, (2) what RDF vocabulary 
is being presupposed in order to refer to datatyping schemes in 
general in the RDFS examples, and (3) the particular datatyping 
schemes in use in the examples, and the particular vocabulary assumed 
to be associated with them; and (4) any assumptions about this 
'reserved' RDF(S) vocabulary that are assumed by the proposal, eg P++ 
will have make some pretty strong assumptions about upward 
compatibility with respect to rdfs:subClassOf, and those ought to be 
stated clearly in order to make the comparisons more reasonable. In 
other words, each proposal needs to put all its cards on the table. .

>My hope is that it
>is possible to have a shared core interpretation that contains the key
>entities in the domain of discourse, labeled for reference. The
>individual schemes introduce specific vocabularies, map nodes in graphs
>to the entities in DD in different ways, and yield additional
>(explicitly denoted) property extensions.

Well, OK, but bear in mind that a given syntax might have many 
different interpretations, so that its something of a stretch to 
claim that any piece of syntax *is* the representation of any 
particular interpretation; and more seriously, perhaps, the pieces of 
this interpretation that count as part of the datatype are going to 
have to be different between the various schemes.

>The shared core would allow
>relating the representations to each other precisely and efficiently.
>Without a common "mind map" we'd have to explain over and over again
>what exactly a given token is supposed to denote in each scheme. (As an
>aside, an interpretation like the one in the diagram might be helpful
>for discussing reification, too).
>Please give me a green light for working the example into the document

Oh yes, green, of course. (Sergey, you need a light from ME??)


IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 13 November 2001 21:50:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC