irc chat re reification

including Jan trashing my new 'argument'...

---------- Forwarded message ----------
Date: Wed, 27 Feb 2002 16:45:38 GMT
From: danbri@fireball.danbri.org
To: danbri@w3.org


IRC logs from Jan and Dan's ongoing discussion of who is right about
 reification...

<jang> s, p, o are of one of the forms:
<jang> <uriref>
<jang> "literal"
<jang> _:a
<jang> the things in a statement _must_ be names
<jang> you had more of a look at the reification thing yet?
<danbri> I thought of a new argument.
<jang> go on
<danbri> If an RDF document contains any statements that aren't true, then it won't be true, right?
<jang> be careful
<danbri> elaborate...
* danbri was being careful (/ sneaky...)
<jang> if an RDF document contains any statements which, in my interpretation I, are not true
<jang> then (since it's a conjunctive logic)
<jang> the interpretation of the document as a whole in I will be false.
<jang> but go on
<danbri> And we try to have some commonality between interpretations when using RDF in the Web community...
<jang> yeah, we suppose some kind of I_w3c which assigns common meanings to literals and resources, at least
<danbri> Next... note that there are no guarantees from RFC2396 (or other Web arch specs) that all strings formatted to URI-2396 syntax are actually names.
<jang> I'm not sure that matters, but go on again
<jang> actually, hold up
<danbri> consider an RDF document that include 1 or more statements made from 1 or more  URIs that don't (in the Web (our interpretation)) denote anything
<danbri> can that document ever be true?
<jang> you mean, there's no guarantee that I_w3c assigns a commonly understood denotation to everything that looks like a URI?
<danbri> I mean RFC2396 defines URI syntax, there are things (We'll call URIrefs) that meet that syntax (and loosly we call 'identifiers') that don't (always) actually have a (commonly understood) denotation.
<danbri> They (on several readings of webarch) aren't names/identifiers for anything at all.
<danbri> (unless we take sneaky approach of having a default denotation, eg. they all refer to the resource named file:/dev/null
<danbri> So anyway, no great mystery to this argument. If we agree that the document just described can never be true, do we further agree that any document that reifies its statements can also never be true?
<danbri> ====
<jang> no
<jang> we don't
<danbri> no? where do we part company? (noting that I don't have any religious attachment to this argment/view, it just popped into my head y/day morning)
<jang> 1. (there's a 0. but I'll come back to that)
<jang> 1. reification models statements, doesn't assert them
<jang> dan said that jan is a girl.
<jang> that could be true.
<jang> there is no quoting
<jang> the 0. is...
<danbri> Forget reification for now. I know (1.) and should be pretending to be offended that you'd suggest otherwise.
<jang> ok, well, you're confusing (it seems) "truth" and "definedness"
<jang> ie, if there is no value in interpretation I for the denotation of <eg:bar>
<jang> then you're saying statements involving it are false
<danbri> A reification model/description of some statement will include statements like "there exists an rdf statement and it has an rdf:predicate property whose value is the resource <blah>"
<jang> when really, they're undefined
<danbri> ...and those statements won't be true if the name '<blah>' doesn't denote anything.
<jang> reification is a mechanism that involves modelling statements within a graph
<danbri> I'm agnostic about whether we say false, or just undefined.
* danbri nodds
<jang> it does not touch on any model-theoretic considerations
<jang> three'sa _big_ difference between false and undefined
<jang> certainly, if you have some "partial interpretation"
<jang> then any reification fo an undefined statement in the partial interp. will also be undefined in meaning
<jang> _not_ false.
<danbri> So I hope we agree that rdf reification, if useful, should allow us to add serialisations of reifications of graphs to our rdf/xml documents without making the true of our rdf/xml doc depend on the names in the reified graph actually referring...
<jang> but the MT doesn't care about that, it doesn't _require_ all possible Is to give everything values...
<jang> it just talks about the consequences of "conforming, proper interpretations"
<jang> ie, it _defines_ an interpretation as something that gives a denotation for everything in the graph
<jang> then talks about what that graph means in terms of that interpretation
<jang> hagn on, just parsing your last "so i hope..."
<danbri> The MT is (quite properly) not concerned with formalising the detail of how URIs denote anything. It takes that machinery for granted (and isn't designed to help us think about case where URI-like symbols never denote).
<danbri> s/the true/the truth/
<danbri> sorry for the unparsable... writing in irc long sentences not good
<jang> the answer to your question is yes, we agree, but routing everything through serialisations and rdf/xml is a red herring.
<jang> (that's not an objection, just an observation: your assertion can be simpler, I thikn)
<danbri> Yup, I thought talking about concrete rdf/xml docs might just help to ground the example, that's all.
<jang> let me guess where this is going...
<danbri> I should be able to update example1.rdf to describe (using reification) some stuff you told me in example2.rdf, and not have example1.rdf become false simply because you typo'd in some URIs that I copy into an <rdf:predicate rdf:resource="ghttp://jan's-typo"/> element.
<jang> yes.
<danbri> example1.rdf can't be true unless ghttp://jan's-typo denotes, right?
<jang> i thought so
<danbri> another reason for talking in terms of rdf/xml is the hope of a test case coming out of this (since this stuff is so damn hard to discuss effectively).
<danbri> Do you see my concern? / any merit in this line of reasoning?
<jang> so the crux of your argument is:
* danbri should stop asking two questions on one line...
<jang> dan writes a document that asserts
<jang> <eg:bar> <eg:foo> <eg:baz>
<jang> or rather, that doesn't
<jang> and I reify it
<jang> and get
<jang> X <rdf:subject> <eg:bar> .
<jang> and my intended interpretation has no value for <eg:bar>
<jang> then something's broken
<jang> is that it?
<danbri> yes, though perhaps with some futzing about 'intended interpretation' to take account of their being no IETF/W3C-sanctioned interprtation (in our example) in which <eg:bar> refers.
<jang> I see your concern, but I think it's misplaced. What you're after are "contexts", which, if RDF had them, we'd all be using for this.
<jang> however...
<danbri> hmm, contexts means all things to all people.
<jang> contexts as in, guha contexts
<danbri> BTW can I copy this IRC log to www-archive, afterwards?
<jang> yeah, don't see why not, I'd appreciate pat Hayes telling us we're both sad and mad
<danbri> :)
<jang> basically though, RDF documents don't come with an intended interpretation; they're symbolic
<jang> and reification is a graph manipulation thing, ie, it comes "before" an interpretation
<jang> if you want to capture intended interpretations then...
<jang> 1. reification isn't what you want
<danbri> So, RDF doesn't have contexts. And URIs are a bit vague. But we want to be able to say that RDF documents (in some publication/assertion context) mean something, that they make claims about the state of the world, and can be true or false.
<jang> 2. rdf isn't what you want
<jang> 3. you're going to have a hell of a job doing it (ie, it's impossible)
<jang> to elaborate:
<jang> if you have some name for me (<eg:jan>)
<jang> how do you say what you intend that to denote?
<jang> except by looking at relationships with other names
<jang> there is no mime type realworldentity/person
<jang> and apache doesn't know how to deliver me
<danbri> I know all this; theories of reference all suck. But RDF and/or the Web make some assumptions about the workings of names, and those assumptions (I'm claiming) have impact on other areas of the RDF spec. Like (in this current discussion) about the safest form of reification...
<jang> I don't think this argument is valid, because denotation functions don't make any claims of existence of things in any real-world sense.
<jang> anyroadup, this is moot unless you can point out: 1. a definition of that funciton f that satisfies all of the constraints placed upon it in that document, or
<jang> 2. which of those constraints 9all of which seem reasonable) you're going to relax
<jang> I want an enron rubber duck

[snip :-]

Received on Wednesday, 27 February 2002 12:41:34 UTC