- From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
- Date: Thu, 18 Oct 2001 10:24:10 +0100
- To: Sergey Melnik <melnik@db.stanford.edu>
- Cc: RDFCore WG <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. 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).
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 (though
I think that Peter Patel-Schneider's "radical reinterpretation" might
handle this more easily, as it introduces separate graph nodes for each
property instance).
>2. CRITERIA
>===========
>
>Below is a non-exhaustive list of several criteria that can be used
>for deciding on the suggested approaches. I picked the criteria that
>affect applications critically.
>
>(C1) backward compatibility wrt existing data and applications
Yup.
>(C2) comparing values for custom or unknown datatypes
> (Is myint:05==myint:5? Given _x1 decimal "5" and _x2 decimal "5",
>is _x1==_x2?)
I think that these equivalences, in general, cannot be fully resolved at
the level of core RDF. As someone else has suggested, we want to be alert
to possible future directions without necessary solving every problem in
RDF 1.0.
>(C3) is typing information self-contained or requires external schema
>[DC2]
Neither of these -- see above.
>(C4) are multiple type assignments allowed? (e.g. US dollar, decimal)
What does this mean? I think a literal can stand for different typed
values in different contexts.
>(C5) compactness (verbosity of serialization, storage efficiency in
>databases, elegant APIs)
I'm reminded of an old adage, something like:
simple things should be simple, complex things should be possible.
#g
>REFERENCES
>==========
>
>[DC1] Dan Connoly. http://www.w3.org/2001/01/ct24
>[DC2] Dan Connoly.
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0338.html
>[JG] Jan Grant. http://ioctl.org/rdf/literals
>[OL] Ora Lassila.
>http://lists.w3.org/Archives/Public/www-rdf-logic/2001Oct/0099.html
>[PH] Pat Hayes.
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Oct/0164.html
>[PPS1] Peter F. Patel-Schneider.
>http://lists.w3.org/Archives/Public/www-rdf-comments/2001OctDec/0057.html
>[PPS2] Peter F. Patel-Schneider.
>http://lists.w3.org/Archives/Public/www-rdf-interest/2001Oct/0054.html
>[PS] Patrick Stickler.
>http://lists.w3.org/Archives/Public/www-rdf-interest/2001Oct/0051.html
>[SM1] Sergey Melnik.
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Sep/0444.html
>[SM2] Sergey Melnik.
>http://lists.w3.org/Archives/Public/www-rdf-interest/2001Feb/0090.html
>[TBL] Tim Berners-Lee.
>http://www.w3.org/DesignIssues/InterpretationProperties.html
>[M&S] http://www.w3.org/TR/1999/REC-rdf-syntax-19990222/
------------------------------------------------------------
Graham Klyne MIMEsweeper Group
Strategic Research <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------
Received on Thursday, 18 October 2001 06:15:16 UTC