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

Re: TDL conflicts with the "duh!" requirement

From: Dan Connolly <connolly@w3.org>
Date: 28 Jan 2002 06:53:34 -0600
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: Jeremy Carroll <jjc@hplb.hpl.hp.com>, RDF core WG <w3c-rdfcore-wg@w3.org>
Message-Id: <1012222415.5187.177.camel@dirk>
On Mon, 2002-01-28 at 03:45, Patrick Stickler wrote:
> 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.

For all literals period. (except parseType="Literal" ones,
i.e. structured XML Literals)

Just like in perl, tcl, and that sort of language.

> Surely you are not saying that any
> arbitrary string has a single interpretation?

Yes, I am.

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

You seem to regard that as a fact. I see it as one
of the design choices; a design choise with very
bad consequences.

As experience with perl, tcl, etc. shows, it's quite workable
to have just one literal datatype and handle a broad range
of use cases.


> Two literals may be string equal, but not denote the same
> value.


That's one design choice. It's not the one I prefer,
and it's not the way the S proposal works.

> Literals are local names and we need the "namespace"
> context provided by a datatype to differentiate between
> different meanings.

No, we don't.


> >> 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.

No, it won't.


> >> 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.

On that we are agreed...

> > 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?

It seems natural to me; your use of subproperties would work as well.

> 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:Description rdf:about="#frLabel">
>    <rdfs:subPropertyOf rdf:resource="&rdf;label/>
> </rdf:Description>
> 
> 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")
> etc.

right.

> > 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.

"scoping"? I don't follow you here.

> >> 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.

I don't mean to change the semantics of subPropertyOf at
all; they're given by the rule:

	?s ?p1 ?o.
	?p1 subProprtyOf ?p2
	===>
	?s ?p2 ?o.


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

One of those relationships may be a corrolary of the
rule above; I'm not sure. But regardless, the
rule above suffices to deffine subPropertyOf.



-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/
Received on Monday, 28 January 2002 07:53:54 EST

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