RE: I18N Issue alternative: a passing thought.

> -----Original Message-----
> From: ext pat hayes [mailto:phayes@ihmc.us]
> Sent: 19 September, 2003 19:58
> To: Stickler Patrick (NMP-MSW/Tampere)
> Cc: w3c-rdfcore-wg@w3.org
> Subject: RE: I18N Issue alternative: a passing thought.
> 
> 
> >  > -----Original Message-----
> >>  From: ext pat hayes [mailto:phayes@ihmc.us]
> >>  Sent: 18 September, 2003 20:24
> >>  To: Stickler Patrick (NMP-MSW/Tampere)
> >>  Cc: w3c-rdfcore-wg@w3.org
> >>  Subject: Re: I18N Issue alternative: a passing thought.
> >>
> >>
> >>
> >>  >It does offer a few benefits. Two significant
> >>  >changes are that it would
> >>  >require equality of values, even plain literals, to
> >>  >be defined by rule, rather than node equality
> >>  >in the graph syntax.
> >>
> >>  ? No, I don't think so. That is, each node will denote a single
> >>  value. Of course two different nodes could denote the 
> same value, but
> >>  then that is already the case and has always been.  Even in our
> >>  present design, there is nothing to stop a bnode denoting the same
> >>  thing as a literal.
> >
> >But you have to look at statements *about* those bnodes to
> >determine what those values are, not at the node (or node
> >label) itself.
> 
> True. But then you have to do that generally in RDF, right?

No. Not for the fundamental tests for node equivalence.

Sure, you might define rules which infer owl:sameIndividualAs
relations based on constellations of properties, but given
two nodes denoting typed literal values, in isolation, you'd
not be able to determine their equivalence, as is now the 
case.

> >Thus, equality is based on some rule that equates constellations
> >of statements in the graph with each other, not nodes based
> >on their expression alone in the abstract graph syntax.
> 
> Well, true, for bnodes: but that has always been true. The literals 
> themselves however can have their identity checked by string matching 
> on their form.
> 
> I see what you are getting at, I think: in our current design, all 
> the information to check identity of typed literals is right there in 
> the literal, whereas in this design there aren't any typed literals, 
> only bnodes, and you have to go look in the graph for the datatype 
> information. True.

Exactly.

At present, one can conclude equality in cases where the node 
representation/label is identical. Using bnodes would mean
that *no* literal value could be comparied simply based on
the representation of a specific node in the graph, as is
now the case.

> >
> >>  >It would also make literal values untidy
> >>
> >>  The bnodes (or URIs ) are just as tidy as the rest of the graph.
> >
> >Eh? What?
> >
> >Are you telling me that
> >
> ><rdf:Description rdf:about="#foo">
> >    <ex:bar rdf:datatype="&xsd;integer">10</ex:bar>
> >    <ex:bar rdf:datatype="&xsd;integer">10</ex:bar>
> ></rdf:Description>
> >
> >is going to map to
> >
> >    <#foo> ex:bar _:g .
> >    <#foo> ex:boo _:g .
> >    _:g xsd:int "10" .
> >
> >merging the value nodes because they denote the same value,
> >rather than
> >
> >    <#foo> ex:bar _:g .
> >    <#foo> ex:boo _:k .
> >    _:g xsd:int "10" .
> >    _:k xsd:int "10" .
> >
> >???
> >
> >I think the latter is what we'd have to get,
> 
> Yes
> 
> >since otherwise,
> >it demands that RDF parsers fully grok every single datatype
> >encountered in the RDF/XML, and the latter is most certainly
> >*not* tidy.
> 
> Well, it is a tidy graph: each bnode and literal is a unique node in 
> the graph (that graph has 4 nodes and 4 arcs, arranged like a 
> horizontal diamond with #foo at one end and "10" at the other). But 
> the proposal breaks when you want to have English and French versions 
> of "chat".

Well, based on the multitude of datatyping discussions we've had "tidy"
to me means that for any given representation of a given value, there
is but one instance of that representation in the graph. Since in this
case there are two instances of the bnode + datatype property statement
representation for 'ten', it is not tidy.


But since we seem to be letting this issue die, nevermind ;-)

Patrick

Received on Monday, 22 September 2003 02:02:55 UTC