W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

Re: TDL conflicts with the "duh!" requirement

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Mon, 28 Jan 2002 11:45:39 +0200
To: Dan Connolly <connolly@w3.org>, Jeremy Carroll <jjc@hplb.hpl.hp.com>
CC: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B87AEA63.C6C8%patrick.stickler@nokia.com>
On 2002-01-25 21:38, "ext Dan Connolly" <connolly@w3.org> wrote:

> On Fri, 2002-01-25 at 13:09, Jeremy Carroll wrote:
>> Dan:
>>> Brace yourself for mind-bogglinly deep
>>> formal argument:
>>> premise:
>>> <http://www.w3.org/> dc:title "W3C".
>>> conclusion:
>>> <http://www.w3.org/> dc:title "W3C".
>>> That's it.*
>> IMO we want this case to hold, but that it is not necessarily the case that
>> we always want "W3C" = "W3C".
> Who's "we"? I always want "W3C" = "W3C". ;-)

But this presumes an implicit, global datatype for all values
of a given predicate. Surely you are not saying that any
arbitrary string has a single interpretation?

As many examples have show, the same literal can -- in the
context of a given datatype -- mean very different things.

Two literals may be string equal, but not denote the same
value. Literals are local names and we need the "namespace"
context provided by a datatype to differentiate between
different meanings.

>> For instance, if we allow literals as subjects,
> I want that. (eventually; I don't mind syntactic limitations
> in 1.0, but I agree we shouldn't do anything today to prevent
> doing this later)

Tidy literals will prevent any adoption of literals as
subjects in the future.

>> and say use xml:lang to
>> generate triples (which I think some members of the group would like) then
>> in general a string in one lang is not the same as the same string in
>> another lang.
> I very much dislike that sort of design; i.e. I consider the
> use of xml:lang in the RDF schema for RDF schema broken.

I agree. RDF rather needs a consistent, generic mechanism
for statement qualification, which includes such things
as language scoping.

> Some folks implement special magic around literals that allow
> you to distinguish the french label from the english label.
> But I think that stuff is broken; i.e. I think it also
> violates the "duh!" requirement.
> I much prefer
> rdfs:Class rdfs:label [ newLangVocab:en "Class"].
> rdfs:Class rdfs:label [ newLangVocab:fr "Classe"].
> especially since I learned there's an RDF 1.0 syntactic idiom for this:
> <rdfs:Class rdf:ID="Class">
> <rdfs:label newLangVocab:en="Class"/>
> <rdfs:label newLangVocab:fr="Classe"/>

Why the extra layer of anonymous node? Of you're
going to capture language scoping with predicates
rather than datatyping, why not just use subproperties
of the rdf:label property? I.e.:

<rdfs:Class rdf:ID="Class" enLabel="Class" frLabel="Classe"/>
<rdf:Description rdf:about="#enLabel">
   <rdfs:subPropertyOf rdf:resource="&rdf;label/>
<rdf:Description rdf:about="#frLabel">
   <rdfs:subPropertyOf rdf:resource="&rdf;label/>

Of course, in either case, we still haven't related those
literal values with some standardized name for the languages
English or French (e.g. (xsd:lang,"en") or (xsd:lang,"fr")

> This idiom works with completely vanilla triple handling
> (apis, query languages, etc.)

I'm not sure how this is "vanilla" if an application
must be aware of the particular ontology being used for
scoping. I think a more generic mechanism is called for.

>> I will work on it next week.
> Please consider the related test case I gave a while back
> while you're at it:
> _:somebody ex:leftShoeSize "10".
> ex:leftShoeSize s:subPropertyOf ex:shoeSize.
> RDFS-entail this?
> _:somebody ex:shoeSize "10".

This of course depends on the semantics of s:subPropertyOf.

Does it define a subset relation between value spaces,
and/or lexical spaces, and/or canonical lexical spaces?


Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Monday, 28 January 2002 04:44:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:08 UTC