Re: Dataypes, literals, syntax

On 2002-08-03, Geoff Chappell uttered to Sampo Syreeni:

>But doesn't that just treat the lower layers like syntax for the upper
>layer?

No. The semantics of something having been asserted proper are still
there, and that's just about all the RDF is about. The situation is quite
unlike that in the case of dark triples and gang.

>is that really the type of layering that we want? I'd think that the
>layers should at least be sharing the same domain (i.e. be talking about
>the same things) to be able to claim interoperability between the
>layers.

Not really. What they need, though, is unambiguity. As you say, we don't
want different layers to interpret the same object differently. But
collapsing meanings higher up isn't a problem -- any MT closure capable
RDF engine will do precisely this when it reasons with subproperties, for
instance. Layering something on top of pure RDF just means that RDF itself
will have to have a fairly fine-grained notion of identity, so that
there's room for that sort of manipulation. I think implicitly typing
literals will only make this easier.

>but should it be possible for a two layers to come up with a different
>interpretation of the same node?

Actually I think that this is a problem mainly with the two last idioms in
the current XSD spec, and wouldn't plague the first one or the scheme I'm
suggesting.

>I can see that a higher level could easily infer additional nodes by
>dereferencing the name(s) of the lower level (i.e. by explicitly
>changing the denotation level) but doesn't that likely lead to similar
>problems as appear in the rdf datatype debate - e.g. a property ending
>up with a range that includes the lexical and value spaces of a
>datatype?

Quite. Hence the requirement of compatibility between the notitions of
equality layered on top of each other.
-- 
Sampo Syreeni, aka decoy - mailto:decoy@iki.fi, tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

Received on Sunday, 4 August 2002 06:54:45 UTC