Re: Datatyping: new medium-range proposal from HP

>>>Jeremy Carroll said:
> 
> 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:

Is this in the rdf/xml *syntax* or in the semantics?  It would have
to be the former in order to generate the datatyped literals without
schema information, which is not presently required for going from
rdf/xml to ntriples.  After all, inside the programming language, the
model always includes the type, even if the syntax lets it be elided.

Not sure if a programming language metaphor will appeal to everyone,
even if it works for me.


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

Fine.  Please say more about what rdf:Datatyping is.  Are triple
generated here?

> 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

OK with me.  By 'new types',  you mean two new rdfs:Datatype


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

I think you'll have to say more about this - how clashes?

--

The outline idea works for me, seems possible but *groan* more syntax
changes mean more delays.  We still haven't even decided on potential
abstract syntaxes for plain datatyped literals, delaying everything
else too.

Dave

Received on Wednesday, 2 October 2002 12:31:53 UTC