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