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

Re: 2001-09-07#5 - literal problem

From: by way of <Graham.Klyne@MIMEsweeper.com>
Date: Fri, 14 Sep 2001 22:15:05 -0400
Message-Id: <200109150215.WAA14636@tux.w3.org>
To: w3c-rdfcore-wg@w3.org
[freed from spam trap -rrs]

 Date: Fri, 14 Sep 2001 17:35:20 -0400 (EDT)
 To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
 From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
 Cc: w3c-rdfcore-wg@w3.org

At 10:46 AM 9/14/01 +0100, Jeremy Carroll wrote:

>I wrote:
> >+ Does the WG agree that the new specs should descibe a specific Unicode
> >string to be delivered by rdf:parseType="Literal"?
>
>Graham wrote:
> > I must confess I'm not very clear what this means.
>
>I should clarify (or at least try to :) ).
[...]

Thanks, it's much clearer to me.

At the risk of stating the obvious, I'd like to distinguish:
- a literal specified as an attribute value
- a literal specified as XML element content conforming to #PCDATA
- a literal specified as XML element content conforming to ANY, using 
rdf:parseType="Literal".

In the first two cases, I think the resulting literal is a Unicode string 
corresponding to exactly the content of the property element or attribute.

The third case is less clear to me, and I think is the only case where one 
may consider the resulting literal string is not necessarily an exact copy 
of the property element content.

In this case, recognizing that the content is XML (and is clearly intended 
to be) I think the minimum requirement to be met is that the Unicode string 
value of the literal is an equivalent XML element content.  Again, obvious 
I think.

If the model theory didn't seem to require a concept of literal equality 
I'd be inclined to leave it at that.  At this stage, I see two possibilities:
(a) for parseType="Literal", treat the literal as an infoset (not a Unicode 
string) and define equality based on infoset equivalence, or
(b) apply canonicalization to achieve an equivalent result on Unicode strings.

Now, here's a question, a test-case even:  are the following three literals 
the same?:

(a)  <rdf:Description ex:property="value"/>
(b)  <rdf:Description>
        <ex:property>value</ex:property>
      </rdf:Description>
(c)  <rdf:Description>
        <ex:property rdf:parseType="Literal">value</ex:property>
      </rdf:Description>

I think the first two are, but I'm uneasy about the third one as that is 
signalled as being XML, not just a character string.  Also, what about:

(d)  <rdf:Description ex:property=" value "/>
(e)  <rdf:Description>
        <ex:property> value </ex:property>
      </rdf:Description>
(f)  <rdf:Description>
        <ex:property rdf:parseType="Literal"> value </ex:property>
      </rdf:Description>

#g
--

At 10:46 AM 9/14/01 +0100, Jeremy Carroll wrote:

>I wrote:
> >+ Does the WG agree that the new specs should descibe a specific Unicode
> >string to be delivered by rdf:parseType="Literal"?
>
>Graham wrote:
> > I must confess I'm not very clear what this means.
>
>I should clarify (or at least try to :) ).
>
>The old spec M&S seems to be deliberately vague about precisely which
>triple is generated by say:
>
><rdf:Description>
>   <rdf:value rdf:parseType="Literal"><foo/></rdf:value>
></rdf:Description>
>
>My reading is that it permits
>
>_:anon <rdf:value> "<foo/>" .
>
>and
>
>:anon <rdf:value> "<foo></foo>" .
>
>and
>
>_:anon <rdf:value> "<foo />" .
>
>and
>
>_:anon <rdf:value> "<foo  />" .
>
>etc.
>
>In general, for each feature identify as not in the infoset in XML
>Infoset, I think it is plausible to make examples where the old spec is
>deliberately ambiguous as to what the triple should be.
>
>Another example, (less silly)
>
><rdf:Description>
>   <rdf:value rdf:parseType="Literal"><foo a="a" b="b"/></rdf:value>
></rdf:Description>
>
>My reading is that it permits
>
>_:anon <rdf:value> "<foo a='a' b='b'/>" .
>
>and
>
>_:anon <rdf:value> "<foo b='b' a='a'/>" .
>
>
>
>Either we decide to continue this deliberate ambiguity, or we decide to
>resolve it.
>This is the question I was raising.
>
>The old spec is also quiet about XML comments, XML processing
>instructions, XML namespaces, and references.
>
>Maybe that was wise, maybe it was foolish.
>
>Jeremy

------------------------------------------------------------
Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
<Graham.Klyne@MIMEsweeper.com>
------------------------------------------------------------
Received on Friday, 14 September 2001 22:15:04 EDT

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