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

Re: Graham.Klyne@Baltimore.com, patrick.stickler@nokia.com, jjc@hplb.hpl.hp.com, jos.deroo.jd@belgium.agfa.com

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 30 Jan 2002 14:37:24 +0200
To: Pat Hayes <phayes@ai.uwf.edu>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B87DB5A4.CBB5%patrick.stickler@nokia.com>
On 2002-01-30 5:00, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:

> OK, yet another version of the MT document is now accessible at
> 
> http://www.coginst.uwf.edu/users/phayes/w3-rdf-mt-draft-J.html
> ... 
> This has new stuff in yellow and even newer stuff in pink.

Just checking the yellow and pink stuff... (and a little scan of
the areas I commented on before)... and again, from the viewpoint
of "RDF for Dummies"...

All in all, alot clearer. Some comments (none show stoppers). Stuff
in brackets are general questions related to your MT text, or arising
from my understanding of it (or lack thereof ;-) but are not comments
about the text itself.

--

1. In section 0.2, you say a graph has "urirefs, literal nodes and blank
nodes". Should this actually read "uriref nodes"? As later in the paragaph
you say that a uriref may "also be a node in the graph". So is a uriref
a node and an arc label, or just a label of an arc or node? You also
use both "literal node" and "literal". Is O a literal node or the actual
string?

2. To the end of paragraph 3 of section 0.2, in the last sentence, can
you expand that to "This reflects the fact that urirefs are considered to
have a 'global' meaning, but literals and blank nodes do not." (I know
this is a view not necessarily held by all group members, but I think it
is correct and very useful to stress)

3. Last para of section 0.2, you may want to say "serializations"
rather than "lexicalizations". Both are correct, but I think the
former is more widely used, and hence more readily understood.

4. Section 0.3, para 3, the statement "this means that every blank node in a
merged graph can be identified as coming from one particular graph in the
original set of graphs." is similarly true for literal nodes, right?

[Would you say that a "proper ground instance" of a query graph is
a complete and successful satisfaction of that query?]

5. Section 1.3 (and this may be out of scope until reification is properly
addressed), it would perhaps be useful to make some distinction between
explicit truth insofar as explicit triples are concerned and implicit
truth insofar as what other triples may be implied or inferred from
explicit triples. I'm thinking of the case of the "option 1" view of
reification where S, P, and O are uriref nodes in the graph, not
strings. Each of the S, P, and O triples are true, but the assertion
(S,P,O) that can be inferred from that may not be true or claimed
to be true. Is that clear? If not, nevermind... (for now)

6. Section 1.3, last para, by "node labels denote things" do you
mean uriref node labels? If that includes literal node labels
(literals), then does that contradict the view that literals alone
are unique? Should this be clarified to say that labels denote
things, but literal labels need additional contextual information,
i.e. datatype?

[Following from your discussion in section 2, it occured to me
that it may not be possible to ensure entailment of graphs with
literals within the RDF space, because the RDF graph will always
suffer the limitation of non-canonical lexical forms, and thus
one must execute the mappings from lexical to value space to
ultimately determine equality, and hence entailment. Thus, neither
TDL nor S (nor any datatyping scheme which does not provide native
internalized representations for all values) can ensure entailment
of the actual values -- only of string equality, which may or
may not be useful. Eh?]

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Wednesday, 30 January 2002 07:36:24 EST

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