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: Pat Hayes <phayes@ai.uwf.edu>
Date: Wed, 30 Jan 2002 11:29:24 -0600
Message-Id: <p05101043b87dd3586ac4@[]>
To: Patrick Stickler <patrick.stickler@nokia.com>
Cc: w3c-rdfcore-wg@w3.org
>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

It is correct as stated, but obviously unclear. I have add some 
sentences of explanation, to make it clear that this is not a typo.

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

OK, and Ive added some more prose to explain why its done this way.

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

Er..yes, though I don't need to emphasize it because I don't use it; 
and IF we decide to go the S-style route for datatyping then all this 
will go away, so I'd rather not go on about it more than we really 
need to at this stage.

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

Hmm, good question. My instinctive logicians-hat-on reply would be 
yes; but Ive learned that what I think of as an answer to a query is 
a lot simpler than what SQL folk think it is, eg this kind of answer 
wouldn't allow you to ask *how many* instances there were, things 
like that.

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

I think I'll leave this until we do reification. I wouldnt want to 
mess with the idea of truth, however.  [BTW, I would say that in 
option 1, there should be *no* entailment in either direction between 
a triple and its reification. Isnt that what people use it for, to 
encode a triple without asserting it?]

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

Well, it all depends on what datatyping scheme we settle on. Like I 
said, Im trying to avoid that issue in this version as far as 
possible. The single-global-mapping assumption is either a stop-gap 
waiting for a later extension of the MT where datatypes will be more 
fully involved with the machinery and a more complicated story will 
get told about them, or else is a sketch of the S proposal which (as 
far as the MT  is concerned) amounts to just saying that all literals 
denote strings. Either way, it will need to be re-done.  When we 

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

In the S proposal, RDF entailment itself will not 'deal with' 
datatypes in any special way and we could make graphs be tidy on 
literal nodes.  For the other proposals, I would expect to introduce 
another semantic extension (dt-interpretations and dt-entailment) 
that would deal with those mappings.

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

Well, it may not be useful, but that's not the MT's problem. If 
literals denote strings, then that's what they denote. If you wanna 
talk about values, you have to write some more triples, right?

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Wednesday, 30 January 2002 12:29:07 UTC

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