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

Re: 2001-09-07#5 Literals

From: Jan Grant <Jan.Grant@bristol.ac.uk>
Date: Fri, 19 Oct 2001 11:48:28 +0100 (BST)
To: Bill de hOra <bdehora@interx.com>
cc: w3c-rdfcore-wg <w3c-rdfcore-wg@w3.org>
Message-ID: <Pine.GSO.4.31.0110191146120.11492-100000@mail.ilrt.bris.ac.uk>
On Fri, 19 Oct 2001, Bill de hOra wrote:

> Tim Berners-Lee:
> >>
> The idea of any "SHOULD" in the definition of equality for literals for
> any
> language give me the creeps.
> >>
> Which is to say 'should not' is inviting non-interop. Spot on. I reduced
> this constraint to 'should not' for a number of reasons, notably
> backward compatibility with text in the M&S, which fudges how lang tags
> affect comparison, and of which 'should not' is a reasonable
> interpretation, and the fact that a lang tag is optional. But really it
> all boils down to this sentence in the M&S:
> [[[
> the language of a literal is considered by RDF to be a part of the
> literal.
> ]]]
> The problem with that sentence is the word 'part'. Without falling down
> a mereological rathole, using 'part' there without some kind of
> explanation of what that means isn't helpful. Especially when the lang
> tag is mandated to add no information to the consequent graph, and, the
> processor is expected to indicate how it deals with lang tags. None of
> this helps interoperability.

I keep on seeing this. It isn't true. The lang tag might not cause any
new nodes and arcs to be added, but it _does_ add information to the
graph, because the literal node is labelled

	(language, content)

and is  distinct from the node labelled


...even if the contents are lexically identical.

jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.
Received on Friday, 19 October 2001 06:49:09 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:53:52 UTC