W3C home > Mailing lists > Public > www-rdf-interest@w3.org > February 2003

Re: Statings -- Much ado about nothing

From: pat hayes <phayes@ai.uwf.edu>
Date: Fri, 14 Feb 2003 09:59:23 -0600
Message-Id: <p05111b20ba72b7a5a99a@[10.0.100.86]>
To: Bob MacGregor <macgregor@ISI.EDU>
Cc: www-rdf-interest@w3.org

>Sorry for a rather sluggish reply:

....

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

I see what you mean, but no cigar. First, integers are (or can be) 
resources: in RDF, *everything* is a resource. Second, it would be 
fine for the type of O to be some subclass of integers, or even to be 
any class that could possibly overlap with integers; so the only way 
you could get a tight constraint would be to use OWL and check that 
the class of O did not intersect xsd:Integer. Since xsd:Integer is a 
class of literal values, your ability to say much about it is 
severely limited in OWL-DL; you should probably use OWL-Full.

>  Actually, while I'm guessing that this particular
>constraint is intended by RDF's reification semantics, I can't be 
>sure.  Is it?

See above. Essentially yes, but RDF doesn't itself give you much 
machinery to do anything about 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.

It doesn't say anything ELSE about reification.

Reification, as you may know, is highly deprecated by the serious 
logicians on the OWL group. I personally tend to agree with them: I 
wish it wasn't even in the language, I think its a crock. But clearly 
we purists are in a minority here, so we've tried to make the best of 
it.

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

If you think that reification is a can of worms, just try getting 
agreement on ways of referring to pieces of syntax in documents. Just 
saying 'fragID' in public can get sniper rifles trained on you. What 
seems obvious is that this is a huge problem and one that goes way 
beyond the RDF WG's charter. I think it ought to be done by the group 
which defines URIs.

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

You are right to complain that there is a kind of hole here in the 
RDF specs, but it goes beyond reification. There is no way provided 
to attach a referring name to *anything*, as far as I know. I 
sincerely hope that some appropriate body will actually do something 
about this fairly soon, but it's too big a job for the RDF core WG.

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
Received on Friday, 14 February 2003 10:59:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:58 GMT