Re: Statings -- Much ado about nothing

Sorry for a rather sluggish reply:

At 10:15 AM 2/10/2003 -0600, pat hayes wrote:
>>Pat,
>>
>>>In the very message you cite, I say explicitly that since you know that 
>>>a statement has one subject, you can infer that <ex:a> = <ex:b>. I 
>>>didn't say that a statement could have two subjects. It can't.
>>
>>We are using the open world assumption in RDF.  When I say two, or twenty 
>>subjects,
>>I'm referring to URIs, not denotations in the real world.
>
>I think I am talking about the same thing. But can you phrase your point 
>in more precise terms? It gets a bit murky because when talking about 
>reification, the 'real world' contains URIs, so the distinction you seem 
>to be drawing here starts breaking down.
>
>>Since RDF cannot verify denotations,
>>that's the best you can expect.
>
>That makes no sense to me. What do you mean by 'verify a denotation'? The 
>only way to verify a denotation in ANY language is to go and actually look 
>in the world which is the intended interpretation. You need more than 
>inference to do that: you need legs and eyes, or something like them. RDF 
>has no equality, but OWL (for example) does, so you might be able to infer 
>that S1=S2 in OWL. Is that 'verifying a denotation'?

People can do such verification; computers can't. So we agree.



>>>But there is no way to express *IN RDF* the uniqueness condition. How 
>>>could there be? Try it yourself: go on, write me a message with some 
>>>triples in it that would follow from knowing that there was only one 
>>>subject to a statement. Remember, you don't have any equality symbol.
>>>
>>>>  Pat Hayes states that the above example is 'peculiar', but
>>>>there is nothing in the RDF model theory that supports such an opinion.
>>>
>>>Not in the formal MT, no. Again, I challenge you: try writing some 
>>>truth-conditions which would support the intuitive account. I'll buy you 
>>>a dinner some time if you can do it.
>>
>>We both know that there aren't any equality constraints in RDF. But, the 
>>possible world
>>semantics
>
>??What possible world semantics?
>
>>says that if I have two triples
>>    S1, P, O  and
>>    S2, P, O
>>then for one of the possible interpretations, S1 and S2 denote the same 
>>thing.
>
>Im not aware of any such statement in any semantics. Certainly this might 
>not be true in any *satisfying* interpretation (depending on the 
>particular triples involved and what semantic constraints are being 
>applied.)   [Later: Oh, wait. This is indeed a consequence of the Herbrand 
>theorem for simple interpretations. But it might fail to hold in more 
>complex kinds of interpretation, eg when datatyping is present.]
>
>>  Therefore,
>>if I write a stating ST that says
>>     subject ST S1
>>     subject ST S2
>>     predicate ST P
>>     object ST O
>>the verifier can't object to the validity of this stating (or any other).
>
>What 'verifier'? That terms isn't used anywhere in the RDF spec as far as 
>I know. Do you mean an RDF syntax checker? If so, then yes, it can't 
>object to that. Nor should it, since for example this might make perfect 
>sense to an OWL reasoner. If you mean an RDF inference engine, then I 
>guess whether or not it objects depends on what it is able to deduce. For 
>example, I can imagine an engine which complains if it is unable to infer 
>conclusively on other grounds that S1=S2 (that would be a verifier using 
>OWL-like reasoning) or one which just goes ahead and infers that S1=S2 
>(that would be more like an opportunistic inference machine).

By verifier, I am thinking of something that performs semantic 
checking.  For example,
suppose  we have the statements

    S1 type statement
    S1 subject S
    S1 predicate P
    S1 object O
    P range xsd:Integer

I can imagine that a semantic checker might signal an error if 'O' has a 
type other than
integer (e.g., if its a resource).  Actually, while I'm guessing that this 
particular
constraint is intended by RDF's reification semantics, I can't be sure.  Is it?


>The RDF spec is carefully worded so as not to impose any constraint on 
>what a hypothetical RDF engine can or can't DO, by the way. For all I know 
>there might be invalid RDF reasoners out there doing useful work, eg 
>making closed-world assumptions based on non-RDF-accessible information. 
>(How can we possibly legislate what software does or doesn't do?) But if 
>they get into a pickle as a result of being invalid, then they took the risk.
>
>>
>>>>Furthermore, if an RDF engine were to complain about it, I would
>>>>consider that engine to be operating as an *extension* of the RDF spec,
>>>>as it has currently been written.  Hence, it would not, strictly
>>>>speaking, be an RDF engine.
>>>
>>>Nonsense. Of course it would. The spec specifically gives rules for such 
>>>extensions.
>>
>>First, you would have to provide more machinery (e.g., Seth's containedIn
>>property).
>
>No, the extension can do that (as OWL does) so long as it conforms to the 
>RDF spec. We give quite precise conditions for such conformance.

OWL extends RDF, but doesn't appear to say anything about reification.  If 
it did, then
I'd be happier.


>>  And, you would have to insist that if the triple you looked for wasn't
>>there,
>
>Wasn't where?? Anywhere on the semantic web? (This seems to me to be the 
>central issue here, by the way. You seem to have in mind a use for 
>reification in which it is a description of a particular named document, 
>which is available for inspection so can be 'validated' against the 
>description. That isn't a primary use case that we have been previously 
>asked to consider, and indeed the RDF spec provides no way to refer to a 
>particular document. In general, naming things seems to me to be a larger 
>issue than just for RDF to decide on, and probably needs to be looked at 
>by a TAG.)

Wasn't in the document/model indicated by URI in the 'containedIn' triple.
Probably my main objection to the reification documentation is that it goes
out of its way NOT to illustrate a means for connecting up a reified statement
to the triple it refers to.  I understand that the WG charter forbids you from
adding anything like that to the RDF language, but if in fact the majority of
the committee has a fairly good idea of what they would like to see (if only
the charter had let them) then putting such an example  in the documentation
might make things a whole lot clearer.

For example, I can speculate that the hypothesized usage of reified statements
(e.g., when expressing provenance information) would in fact typically 
include a triple
that identifies the document containing the triple that the reified triple 
refers
to, but nothing in the RDF documentation that I've
read indicates what the "normative" usage is.


>>then the stating isn't valid
>
>Valid in what sense? And why would you make that inference? Why would you 
>not conclude that there must be some other information that you don't yet 
>know about? You might have only partial information about the stating, 
>after all.
>
>>(right now, the triple could reside in Timbuktu).
>
>Yes, it could. What did you expect? RDF is all about putting together 
>information from disparate sources.
>
>>Then, you would need to get your new  property and semantics blessed by
>>W3C
>
>Well, to define a new semantic extension might be quite a bit of work, but 
>it can be done. I don't see why it requires W3C blessing: I would expect 
>that all kinds of people and companies will define their own semantic 
>extensions. As long as they impose them on a vocabulary that they own, and 
>stay conformant to the spec., I see no long-range interoperability 
>problems with that.

Unregulated invention of new vocabulary for something as fundamental as the 
link between
a reified statement and the statement it refers to is what I'd prefer not 
to see.


>>(or risk an explosion of disharmonious stating implementations).  If making
>>up new semantics for RDF was this easy, we wouldn't need an OWL committee
>>to scrutinize each new predicate.
>
>If OWL did not have a chartered obligation to be based on RDF (in ways 
>that go into much more detail than merely being a semantic extension), 
>things would go a lot more smoothly. And if we were not in such an 
>all-fired hurry. But that isn't a technical matter.
>
>>
>>>>So, how should we interpret Section 3.2.1 of the RDF Semantics document?
>>>It is intended to be informative.

My preference would be to include an explicit EXAMPLE of how to "point" 
from a reified statement
to the statement it is describing. Something like Seth's 
'containedIn'.  This could go into the Primer
rather than the model semantics document, as long as it appears somewhere.
If such an example were included, then of course it would have to be made 
very clear
that the example is not a part of RDF proper.  And if people just happened 
to emulate
that example in their own implementations, that wouldn't be such a bad thing.

Cheers, Bob

Received on Thursday, 13 February 2003 20:06:18 UTC