Re: xmlsch-01 Typed Literal Structure proposal to close

At 14:06 22/04/2003 +0300, Jeremy Carroll wrote:

>Summary: reject.

Summary: I'm wondering if the response misses the point of the comment.

The comment says "surely a reason ought to be given" why we don't describe 
the type of a literal as we did the type of other resources, i.e. with a 
property arc whose subject is the literal to the type.

I suggest:

The WG interprets this comment as two questions and a comment:

   1)  Why is the type of a literal not described using a property arc, as 
is done for other literals?

   2)  Having introduced typed literal nodes, why not introduce typed 
resource nodes and typed property arcs as well

   3)  The WG should provide a rationale for this design in the specifications

Regarding question 1:

This would require that literals be allowed as subjects of RDF 
statements.  This is not possible in current RDF/XML and would require 
considerable change, beyond the scope of the WG, to  support it.    Further 
it introduces problems of non-monotonicity in the semantics.  A property 
whose value is plain literal is currently taken to denote a sequence 
characters.  Adding a further statement could change that value to, say an 
integer, invalidating previous inferences and breaking a fundamental tenet 
of RDF.

Regarding question 2:

No requirement justified a change to the notion of a URIREF node or an RDF arc.

Regarding comment 3:

Providing a rationale document to accompany the specifications would 
certainly be nice to have, but given we don't have the resources to do one, 
must remain so.  We reject this comment on the grounds that the 
specifications are not intended to provide a rationale.


>The comment is
>[[
>    The introduction of pairs consisting of a lexical form and a type (or,
>     strictly speaking, a lexical form and a type label) seems at first
>     glance to complicate the RDF model somewhat. We have had the
>     impression that in other parts of RDF, typing is handled by adding
>     further arcs and nodes. If the type of a resource is identified by
>     having an arc labeled rdf:type from it to (the URI of) its (RDF) type,
>     and if the type of an arc is similarly identified by an arc, then
>     surely a reason ought to be given for shifting to a different method
>     for typing literal strings. It seems like a dramatic shift in the
>     infrastructure of RDF, from "everything is a node, an arc, or a
>     literal value" to "everything is a node, an arc, or a typed literal
>     value". Perhaps not quite so dramatic, after all. But the question of
>     design consistency remains: why not "everything is a typed node, a
>     typed arc, or a typed literal"?
>]]
>
>The propose response is to do nothing.
>
>Here is a draft reply:
>
>[[
>We have considered your comment and rejected it.
>This aspect of the new design has been the one that
>we found the most difficult, and we are not surprised that
>aspects of it seem overly complicated.
>To answer your question as to why we use a different
>means to type literals than that used to type nodes and
>properties:
>- RDF nodes and properties are typically untryped.
>   Type information can be added monotonically,
>   potentially by a further document elsewhere on the
>   Web, or by an inference rule.
>- untyped literals, however, are character strings, or
>   pairs of character strings and language tags.
>   Adding type information, such as maling a speciifc
>   literal node into an xsd:int, is not monotonic, but
>   a destructive operation, in that previously true
>   information, and valid inferences may cease to be true.
>Because of this difference in the behaviour of
>literal nodes from other nodes in response to addiitonal
>type information, the WG decided to provide a different
>mechanism, operating syntactically, rather than the rdf:type
>mechanism which operates semantically.
>
>We remind you that the group was far from unanimous
>in its discussions concerning literal typing, with Mike Dean's
>formal objection being indicative of the minority position:
>http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2003Jan/0173.html
>
>]]
>
>Jeremy
>
>

Received on Tuesday, 22 April 2003 14:15:00 UTC