W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > February 2002

Re: Flower Power and Datatyping ~:-)

From: Sergey Melnik <melnik@db.stanford.edu>
Date: Mon, 04 Feb 2002 13:47:25 -0800
Message-ID: <3C5F016D.A5A9D1BF@db.stanford.edu>
To: Patrick Stickler <patrick.stickler@nokia.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Patrick Stickler wrote:
> 
> 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.

Right, but not in the case when parseType declaration applies to all
subordinate XML structure (I think that's the way parseType works right
now). If only untidy literals are desired, one could place
parseType="untidy" in the root of the XML tree, e.g. at the <rdf:RDF
...> node.

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

Great, I like Jeremy's/your suggestion. The examples above work just as
well in S-P under tidy literals. My understanding was that untidy
literals were needed in TDL only to attach a literal as a property value
directly, w/o rdf:value. If such use is not required, untidy literals
aren't too. The style used in the above example works fine for me.
 
> 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" .

Yep, that's exactly my intention. The only additional detail I borrowed
from Frank is the parseType="untidy" (or something like that)
declaration. If missing, the document can be parsed just as in RDF 1.0,
and no changes to the existing software are required.
 
> 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.

Right, this change could be indicated using the kind of flag that Frank
suggested...
 
> > 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.

To be frank (or Frank? ;), personally I'm agnostic about xsd: vs.
rdfdt:. We'd just have to make the opponents of using xsd: namespace
happy somehow...
 
> 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. ;-)

Thanks for your feedback. In fact, I feel that we are damn close to some
kind of consensus.

Sergey
Received on Monday, 4 February 2002 16:17:25 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:45:03 EDT