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

Re: Datatyping: new medium-range proposal from HP

From: Frank Manola <fmanola@mitre.org>
Date: Wed, 02 Oct 2002 15:02:29 -0400
Message-ID: <3D9B42C5.F2F01B5B@mitre.org>
To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
CC: w3c-rdfcore-wg@w3.org


I want to think about this some more, but I do have an initial
reaction.  It seems to me that the most important aspect of this
proposal is identified in the first sentence:  "file scope".  You then
proceed not to talk about scoping in the rest of the message (pretty
smart if you ask me!), but I don't think we can ignore this. 
Programming languages have scoping mechanisms for the assignment of
types to identifiers other than files.  We've not talked much about
scoping at all, let alone using files for it.  I'm a little hesitant to
want to use file scoping for this purpose without some additional
insight into what else file scoping is used for in RDF-land, whether
file scoping is something we want to "officially" encourage for *any*
purpose (let alone this one), etc.  Or, to put it another way, if I set
my artillery piece to "medium range" and fire it, what do I hit, and how
much collateral damage will there be?


Jeremy Carroll wrote:
> Summary: use file scope syntactic datatyping mechanism.
> After the recent wg fracas about datatyping I have been consulting with my
> colleagues.
> No one in the WG will be surprised to hear that the HP team is split down
> the middle on the tidy/untidy issue.
> However, you may be surprise that we have reached a consensus about our
> preferred solution, with no dissent (within the HP Jena team).
> The first step towards it was to rename "tidy" as "short range" datatyping,
> and "untidy" as "long range" datatyping.
> Having done that, a compromise of "medium range" datatyping seems thinkable.
> Moreover, on further consideration, we determined that our preference for
> this new proposal was sufficiently great that we wanted the WG to consider
> it, despite its lack of timeliness.
> So here goes ...
> =========
> On the datatyping issue we have two camps:
>    camp T want connolly's entailement and an easier life for implementors
> and developers
>    camp U don't want to repeat the rdf:datatype on every instance
> Both of these needs can be met if an rdf/xml parser fully resolves the type
> of literals.  When the triples come out of the parser, they have their
> datatype attached.
> In programming languages we do not write:
>    <int>i = <int> i + 1;
>    if (<int>i < <int>j) then {
>      <int>i = <int>j + <int> i;
>    ...
> We write:
>    int i,j;
>    i = i + 1;
>    ...
> Following that model, add to RDF the ability to make datatype declarations:
>    <rdf:RDF>
>      <rdf:Datatyping>
>        <foo:prop1 rdf:datatypeRange="&xsd;decimal"/>
>        <foo:prop2 rdf:datatypeRange="&xsd;string"/>
>      </rdf:Datatyping>
>       <rdf:Description>
>         <foo:prop1>10</foo:prop1>
>         <foo:prop2>10</foo:prop2>
>         <foo:prop3>10</foo:prop3>
>       </...
> produces:
>    _:a foo:prop1 xsd:decimal"10" .
>    _:a foo:prop2 xsd:string"10" .
>    _:a foo:prop3 "10" .
> The object of the last triple is a literal classic which has tidy semantics.
> Moreover we could combine this with Sergey's suggestion of two new types for
> tradional RDF String Literals, and traditional RDF XML Literals.
> http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2002Sep/0196.html
> Range constraints in a schema are understood as constraints not as long
> range datatyping. Thus with the previous data
> foo:prop3 rdfs:range xsd:decimal .
> simply fails (is contradictory); as would be:
> foo:prop3 rdfs:range xsd:string .
> ====
> This proposal is intended as a sketch, but enough of one to allow active
> consideration. I understand that the WG will soon reconsider the tidy/untidy
> decision, and I ask that this be included as a third possibility.
> As with any of the options, I imagine that once a choice is made further
> refinements will occur.
> I note that DanC has some wizzy multiple choice web voting software (single
> transferrable vote?) that would support a three way choice.
> Jeremy

Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752
Received on Wednesday, 2 October 2002 15:05:23 UTC

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