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

Re: DATATYPES: mental dump.

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Tue, 13 Nov 2001 12:25:56 -0800
Message-ID: <3BF181D4.D745203E@db.stanford.edu>
To: Pat Hayes <phayes@ai.uwf.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?

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

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

> 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, because
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? 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. 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


> Pat
Received on Tuesday, 13 November 2001 14:58:43 UTC

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