Re: Flower Power and Datatyping ~:-)

On 2002-02-01 20:51, "ext Sergey Melnik" <melnik@db.stanford.edu> wrote:

Please don't take me as overly biased or adversarial for
jumping all over this, but...  ;-)

> Now let me try to summarize without using too many plugs.
> 
> The major advantage of the above twist is that all typed values are
> always bNodes. With respect to uniformity of representation, this
> feature beats both all existing S-* idioms and TDL. (In fact,
> depending on global/local use, TDL sometimes deploys bNodes, sometimes
> literals, so applications need to distinguish and use two kinds of
> queries.)

Your proposal seems like it may work, but, as I pointed out
in my reply to Jos's question "why not take just the 2 ???"
we need to put a lot more focus on end user burden that I
feel we are doing.

Having to use parseType for *every* typed literal will be
far too cumbersome.

Furthermore, I'm not sure that it is necessary in order to
achieve the same result.

Compare your suggestion to Jeremy's proposal to always create
a bNode in the graph regardless of whether the local/explicit
or global/implicit idiom is used. I.e. making the 'D'/'P' idiom
the only idiom, but allowing rdf:type to be optional?

[Hmmm... Jeremy, was that posted to the list? I couldn't find
a link to it in the archives...]

In a nutshell it says that you can have either the global/implicit


    foo ex:prop _:1 .
    _:1 rdf:value "val" .
    ex:prop rdfs:range x:someDatatype .

or the local/explicit

    foo ex:prop _:1 .
    _:1 rdf:value "val" .
    _:1 rdf:type x:someDatatype .

or both

    foo ex:prop _:1 .
    _:1 rdf:value "val" .
    _:1 rdf:type x:someDatatype .
    ex:prop rdfs:range x:someDatatype .

with perfect symmetry/consistency and no conflict in
interpretation between global and local idioms.

The global idiom thus becomes simply an incomplete
form of the local idiom which is filled in by the
global range constraint.

That provides for tidy literals, completely consistent graph
structure, and doesn't require any change to the syntax, since
we can simply treat

    <rdf:Description rdf:ID="foo">
      <ex:prop>val</ex:prop>
    </rdf:Description>

as synonymous with (a contracted form for)

    <rdf:Description rdf:ID="foo">
      <ex:prop>
        <rdf:Description>
          <rdf:value>val</rdf:value>
        </rdf:Description>
      </ex:prop>
    </rdf:Description>

or

    foo ex:prop _:1 .
    _:1 rdf:value "val" .

In comparison to the above, which achieves I think the same
results, the manditory use of parseType seems overly cumbersome
to me.

Jeremy's approach doesn't require a change to the XML syntax,
though it would require a change in the XML to graph mapping.

> Only one piece of
> vocabulary per datatype is needed

That's good to hear.

> (a URI like rdfdt:integer).

I am opposed to using separate namespaces for existing datatypes.
Per Frank's comments in rdf-interest, if we're talking about
XML Schema integer, we should use the correct URI.

Also, I don't like seeing datatypes with any 'rdf*' namespace
and/or prefix. RDF does not and IMO should not have native
datatypes. There is no such thing as an "RDF integer".

We should use one URI per datatype, and use the URI that the
datatype creator/author specifies.

> Have a nice weekend,

I did. Thanks. ;-)

> Sergey

Patrick 

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Sunday, 3 February 2002 05:01:02 UTC