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

Re: datatyping discussion

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Mon, 22 Oct 2001 16:09:46 -0500
Message-Id: <p0510103ab7fa38d89260@[205.160.76.193]>
To: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Cc: w3c-rdfcore-wg@w3.org
>At 07:49 PM 10/17/01 -0700, Sergey Melnik wrote:
>>1. SUGGESTED APPROACHES
>>=======================
>>
>>All suggested approaches can be roughly divided into two groups,
>>"typed instances" and "schema-based typing" (also called weak and
>>strong typing [OL]).
>
>I think it's crucial that basic RDF processing does not depend on 
>the availability of schema information.  I think this rules out what 
>has been called "strong typing"...
>
>(... which I would prefer to call "early typing", as there are 
>languages that don't require type declarations but instead infer 
>type information from usage, and still enforce what I would call 
>strong typing, but that's another debate.)
>
>But the above digression does point up that there are other options. 
>The more I think about it, the more I come to think that DanC's 
>approach [DC1] is particularly elegant, as it allows simple untyped 
>use of literals, yet provides a way to incorporate more detailed 
>typing information into the RDF graph where that is required by an 
>application.
>
>[DC1]   Dan Connoly. http://www.w3.org/2001/01/ct24
>
>Roughly, I think Dan's proposal says that:
>
>     subject >-property-> "Literal" .
>
>means the thing denoted by 'subject' has an attribute identified by 
>'property' which has a Unicode string rendering of the form 
>'Literal'.  I think that much current use of RDF leaves it to the 
>application to figure out what value it is that has the indicated 
>rendering, and basic RDF applications can live with this.  Dan's 
>proposal shows how additional arcs can be added to the graph (in a 
>fashion that I would say is similar to the schema closure mechanism 
>in Pat's model theory) to capture more detailed information about 
>the resources.
>
>I think that a key benefit of Dan's approach is that the above 
>statement still results in a graph arc:
>
>    < I(subject), I(property), I("literal") >
>
>where other approaches seem to suggest that this should not be 
>generated, but instead that some pair of graph arcs should be 
>generated.

This is exactly why I like the 'implicit datatyping' approach; it 
leaves literal subjects absolutely alone. However, I can't follow how 
Dan's proposal does this, unless it also somehow allows literals to 
be subjects. Doesn't he suggest transcribing the literal value 10.0 
as the N3 form [ rdf:value "10.0"], which requires rewriting the 
above as

<I(subject), I(property), thing>
<thing, I(rdf:value), literal>

Notice that is not I(literal), since literals don't have I's in this 
picture. (If there were an I(literal) it would be the thing.)  Notice 
that we would need to add some special semantic conditions to 
rdf:value to ensure that it means that its object is the unicode 
transcription of its subject, so rdf:value is not actually standard 
RDF, contrary to appearances.

>I see Dan's approach as allowing the other arcs to be added to the 
>graph if they're needed (and the appropriate information is 
>available).

Right, so does the Hayes/Patel-Schneider approach.

>
>One thing in Dan's proposal that I'm uncomfortable about is that it 
>appears to depend on existentially quantified property identifiers, 
>which seem to be problematic, or maybe just more difficult, in Pat's 
>model theory

They aren't a problem for the MT. However, they are a very real 
problem for the graph syntax. In fact, allowing them would make the 
graph syntax unusable, in practice.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes
Received on Monday, 22 October 2001 17:09:52 EDT

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