Re: summary of reification semantics issues (material for discussion).

I have the feeling that this statements/statings de re/de dicto issue is 
not well-enough understood by a wide enough audience to be nailed down in a 
recommendation at this time.  Real experience is patchy and sometimes 
contradictory.

Tim, from what I see, most of your work in this area has been based on N3 
formulae rather than the "reification" vocabulary, which are in any case 
outside "standard" RDF as currently described.  (I happen to like that 
approach, but that's not the issue here.)

As a working group, we were faced witj this reification vocabulary that our 
charter required we had to do something with.  Deprecation was an option, 
but on balance was not considered right in this case.  I don't think it 
fundamentally needs to be in the RDF base language (one can invent 
additional vocabularies for similar purpose, when required), but that's not 
the starting position we were given.

In summary, I don't think this discussion is greatly helpful for the 
*working group* at this time, and that we should clarify the existing 
vocabulary in a way that is least disruptive, and recognize that it is not 
the last word on these issues.

#g
--

At 16:48 13/03/2003 -0600, pat hayes wrote:

>>Thank you Pat for this summary.  I find in it
>>a conclusion that de-re semantics for reification are useful,
>>which is not the conclusion to which I come. As this affects running
>>code, I will go through the message looking for differences.
>>
>>On Tuesday, Mar 11, 2003, at 18:17 US/Eastern, pat hayes wrote:
>>
>>>Summary of the semantic alternatives for RDF reification.
>>>---------------------------
>>>A reification assertion such as
>>>
>>>aaa rdf:subject bbb .
>>>
>>>is saying that something is the subject of something else which is an 
>>>RDF triple. There are at least two orthogonal dimensions on which one 
>>>can choose alternatives about what exactly these 'somethings' are.
>>>
>>>aaa  might refer to a triple as an abstract grammatical form, or it 
>>>might refer to a particular occurrence of a triple in some actual 
>>>document somewhere. This has been referred to as the 'statement/stating' 
>>>difference.
>>>
>>>bbb might refer to a piece of syntax - the actual subject 'node', or 
>>>subject token in a document - which occurs in the RDf graph, or it might 
>>>refer to the thing that is considered to be the subject of the 
>>>proposition expressed by that triple. This has been referred to as the 
>>>'de-dicto/de-re' difference.  This can be dramatized by asking: is the 
>>>rdf:subject of the triple
>>>
>>>ex:Mary ex:had ex:littleLamb .
>>>
>>>a girl or a uriref  (respectively de dicto or de re)  ?
>>
>>I think you mean the other way around, no?  The de re interpretation is that
>>the subject is the thing, Mary, and the de dicto that it is that which 
>>was said, the
>>URI?
>
>Yes, whoops. Thanks for catching that.
>
>>
>>>These two choices are independent, but each influences the significance 
>>>of the other.
>>>
>>>Currently, the semantics document recommends that one should interpret 
>>>this vocabulary so that aaa is interpreted as a stating, ie referring to 
>>>a concrete occurrence of a triple rather than an abstract form; and that 
>>>bbb should be interpreted de re, ie as referring to Mary rather than to 
>>>Mary's URIref.
>>>
>>>The reasoning behind these choices are as follows.
>>>
>>>Statings allows one to associate provenance information with triples in 
>>>a document a document by using reification to talk about the triples. 
>>>This would be impossible (meaningless) if we imposed the 'statement' 
>>>interpretation.
>>
>>I think this is an argument which doesn't make sense if yo try it.
>>You can't really distinguish between a stating and a statement until you
>>give a test case, which involves more relationships.
>
>The difference is kind of invisible in RDF, but it shows up in OWL.
>
>>While a triple  {ex:Mary ex:had ex:littleLamb} is represented merely by
>>its three parts, there is no association with a particular source.
>>There is nothing to indicate that it is a stating.
>
>True, and that's one reason why we didn't try to formalize this difference 
>but only asserted it in English text. But since this issue had come up 
>several times and seemed to generate a lot of heat, we thought it would be 
>good to state the intention as clearly as we could.
>
>>Suppose that the triple indicates just the abstract statement.
>>We can reify this by giving the strings which make up its parts.
>>
>>ex:s1  rdf:subjectSymbol  "http://www.example.com/pat12#Mary";
>>            rdf:predicateSymbol "http://www.example.com/pat12#had";
>>            rdf:objectSymbol "http://www.example.com/pat12#littleLamb".
>>
>>(I've used "objectSymbol" as you can have "objectLiteral" as well)
>>
>>We can then state that for example passing a given file gives you
>>among other things that:
>>
>><mgoose.rdf>   ex:includes ex:s1.
>>
>>So s1 is just an abstract statement,and we have established
>>a relationship with a source document.  This latter triple, if you like,
>>is an expression of the stating.
>
>Hmmm. But where exactly do you attach the provenance information? 
>Attaching it to the document might be rather coarse, eg suppose I wanted 
>to say that a particular triple was modified at a different time than the 
>original document was composed.
>
>>
>>This is practical.  In cwm, statements are like literals - they can be 
>>compared
>>and interned.
>
>Interesting. In the reification usages, statings are denoted by bnodes, 
>typically. So there seems to be a nice picture emerging here where the 
>*form* is indicated by (things like literals) and the *actual identity* of 
>a stating is indicated by a bnode, and then the reification vocabulary is 
>a way to connect these together. And then ex:includes is a way to connect 
>a stating with its containing document; and your point is that we might as 
>well think of it as relating a stateMENT to the document, and then there 
>is no need to introduce the statING at all. (But there has to be some 
>subject for the reification triples, right? Whether or not we say it 
>denotes a statement or a stating is only marginally relevant to RDF 
>entailment, but it doesnt seem to make sense to attach provenance 
>information to it if it is supposed to indicate a statement.)
>
>This picture actually indicates an ambiguity which has come up elsewhere, 
>eg in datatyping, where we considered one way to interpret typed literals 
>as always referring to strings, but allowed the possibilty of interpreting
>
>ex:mary ex:age "10" .
>
>as meaning 'Mary's age is *a number which can be represented as* the 
>string "10" ', which in effect introduces a kind of ghost bnode in between 
>ex:age and "10" to stand for the number. (We didnt do this, in the end, 
>but the idea is out there.) The statement way of interpreting the 
>reification seems to me to be a bit like this, in that you see a direct 
>relationship between a statement and a document, where I see a two-step 
>relationship between the statement and a stating (expressed by the 
>reification) and between the stating and its document (expressed by 
>ex:includes), and the 'missing' bnode is the subject of the reification 
>triples.
>
>>When the same statement (or formula of >1 statemement,
>>for that matter) occures in many places, it only has to be stored once.
>
>Well, it only has to be described once in either way of doing it, since 
>you could always have a ex:sameFormAs property to connect the bnodes 
>indicating different tokens of the same form, and just give a reification 
>description for one of them.
>
>>It also avoids giving rise to things which one doesn't need to use.
>
>I still don't see what is going to be the subject of the triples encoding 
>the provenance information, if reifications denote statements.
>
>>
>>>Such uses of reification form a large class of actual use cases.
>>
>>Could you give me pointers?
>
>Er...no, sorry. That was based on memory of the discussions in the WG. I 
>think Dan C might be able to give you the pointers (?)
>
>>
>>>On the other hand, if someone wants to describe the abstract grammatical 
>>>form of a statement, this can be done by using a particular instance of 
>>>it as an exemplar for the abstraction, eg by associating a bnode with 
>>>the reification by a property like <ex:abstractformOf>.
>>
>>If there really is a non-abstract form of the statement, then presumably 
>>there is
>>some modelling of it which we are missing which makes it distinct from 
>>the abstract form.
>>
>>I personally find it quite satisfactory to consider that the statement is 
>>the abstract form,
>>that, say, a given formula contains a given statement, or a given source 
>>supports a given statement,
>>but I find no use in the concept of that statement as specified in a 
>>given file as opposed
>>to the same statement as specified in another file.
>
>Well, OK, I guess you can do it either way. In your way of doing it, an 
>OWL engine should be able to conclude that if ex:a and ex:b have the same 
>reification description, then they are the same thing. I guess it seemed 
>easier to me to allow them to be distinct and then they could have other 
>properties, such as a time they were written, an author, stuff like that.
>
>>>The de re interpretation allows reifications to use the same conventions 
>>>for  interpreting URIrefs as other triples, so that a URIref used as an 
>>>actual subject node, and the same URIref used as the object of an 
>>>rdf:subject assertion, have the same meaning. In contrast, the de dicto 
>>>interpretation would require a reasoner to distinguish these two uses, 
>>>using some extra-RDF convention such as quotation,
>>
>>The use of a string literal to indicate the URI of a symbol as above is 
>>not extra-RDF.
>
>Well, knowing that the literal is a piece of RDF is extra-RDF. In fact, if 
>I read the XML Schema specs aright, a string *can't * be a URIref. Mind 
>you, I have very little confidence that I am reading them aright.
>
>>>  or else require that subjects and objects of reified triples be given 
>>> distinct URIrefs which are understood in a 'meta' sense to refer to the 
>>> actual URIrefs in the subject and object position of the reified 
>>> triple. Neither of these formal techniques have emerged in practice, 
>>> suggesting that the de re interpretation in fact codifies existing 
>>> intentions of users.
>>
>>I actually tried the de-re method in generating proofs from cwm, and 
>>found that I was generating garbage.  I was generating things which 
>>looked nice on paper but which were logical nonsense.
>>(The proof-checker would be working through nested formulae and then come 
>>across a small sheep!)
>
>:-) Ive often wondered what a LISP interpreter would do if it found that 
>(cadr X) was a small sheep.
>
>>
>>>One objection to the de re interpretation is that it does not allow for 
>>>the adequate representation of propositional attitudes such as belief. 
>>>This is controversial (see the discussion of the Russellian theory in 
>>>http://plato.stanford.edu/entries/prop-attitude-reports/) , but in any 
>>>case there is ample experience which suggests that the de dicto 
>>>interpretation would produce other problems with the representation of 
>>>such ideas, and that an fully adequate representation of propositional 
>>>attitudes is unobtainable using reification alone.
>>
>>Well, its certainly unattainable using the de-re interpretation, and 
>>without some quoting
>>of the symbols used.
>>
>>But surely, the whole reason for the introduction of reification was to 
>>quote.
>
>I will have to defer on that one. I have no idea why reification was 
>introduced, and would prefer to not touch reification with a barge pole, 
>myself. One of the first things that the CL group did was to decide to 
>take quotation *out* of KIF.
>
>But if that was the point of reification, why not just put a form of 
>quotation into RDF directly? Its SO much easier to follow than having a 
>clunky meta-description, and it avoids a host of problems (eg what sense 
>can be made of a partial meta-description? Its syntactically impossible to 
>have a partial quote.)
>
>>The phrase "propositional attitudes" is a scary one suggesting one models
>>degrees of human belief, and modeling of intelligence and rather more
>>philosophy than one would want to get into.
>
>The phrase is used in linguistics, not meaning to get impossibly 
>ambitious. Just getting the basic logic of things like the Superman 
>examples right is already enough of a problem.
>
>>In fact, we are using quoting (ie de-dicto) to make quite mechanical and 
>>simple statements
>>about what a file parses to, what a rule implies, and so on.  From the 
>>programming
>>point of view it looks straightforward and I haven't found the logical
>>inconsistencies which the de-re interpretation produces.
>
>Well, Im having trouble already. How can you use reification to 
>simultaneously mean quotation *and* to talk about what a rule implies? The 
>conclusion of a rule (= Horn clause) isn't (usually) quoted. Are you sure 
>that there is a single interpretation of reification being used for both 
>cases? Maybe the inconsistencies come from there being more than one sense 
>and them getting muddled inside proofs (? I don't mean to toss mud here, 
>just that this is notoriously hard to keep straight, particularly when 
>things get complicated.)
>
>>To be able to talk about the formula { :Ora :wrote :MobyDick} abstractly,
>>without talking about Ora.
>
>That is OK, but the example in the M&S is where Ora said {some RDF}, and 
>its supposed to be interpreted in way in which you ARE talking about Ora, 
>but the thing that Ora is talking about is reified. Its this kind of 
>mixing that seems to need at least some de re style interpretation. 
>And  often you want to say that Ora said something *about Frank*, and then 
>its surely the de re sense of 'Frank' that you have in mind, and if you 
>have to fully quote what Ora said then there's no way to link it with 
>Frank (as opposed to 'Frank'; you can't even assume that 'Frank' means 
>Frank, because Ora may have a Lois Lane thing going with Frank for all we 
>know.)
>
>>We have found that serious use of semantic web data often involves an 
>>awareness of the provenance of data.  The formulae in N3 are a form of 
>>quoting. A way of
>>giving a formula in RDF by reifying it (describing it in RDF) would be an 
>>interesting and
>>useful alternative to the use of the {}  or parseType="Quote" syntax 
>>extensions.
>
>I vastly prefer { } to reification, myself. Adding { } to RDF would be a 
>huge improvement which would have solved a host of the 'layering' problems 
>with OWL. Reification only made them worse. If we had provided a genuine 
>model theory for RDF reification there would probably have been a riot 
>within Webont, because God alone knows what would happen if you tried to 
>use OWL operations on the reification vocabulary (eg imagine a lower-bound 
>cardinality restriction on rdf:Subject...) .
>
>>The query languages involve RDF which is not asserted, and can be 
>>implemented as quoted,
>>and the return of bindings from a query involves mentioning the variable 
>>names.
>>There are many practical ways in which quoting is needed.
>
>No, really, one doesnt need quotation *in the logic* in order to implement 
>bindings and such stuff. Of course from the implementation point of view 
>all of RDF looks as though it is quoted, because the code is treating all 
>of the language as objects to manipulate. That is normal. But that's not 
>the same as putting those quotes into the assertions themselves.
>
>>I had the impression that
>>that was the raison d'être of the reification in the spec, but one can 
>>only guess at intent.
>
>Indeed. But the examples in the M&S seem to me to have more to do with 
>provenance and indirect attribution (Ora said that...) than implementation 
>of reasoners.
>
>Pat
>--
>---------------------------------------------------------------------
>IHMC                                    (850)434 8903 or (650)494 3973   home
>40 South Alcaniz St.                    (850)202 4416   office
>Pensacola                               (850)202 4440   fax
>FL 32501                                        (850)291 0667    cell
>phayes@ai.uwf.edu                 http://www.coginst.uwf.edu/~phayes
>s.pam@ai.uwf.edu   for spam

-------------------
Graham Klyne
<GK@NineByNine.org>
PGP: 0FAA 69FF C083 000B A2E9  A131 01B9 1C7A DBCA CB5E

Received on Friday, 14 March 2003 06:09:48 UTC