Re: OWL equivalentClass question

On Jul 14, 2012, at 12:15 PM, Alan Ruttenberg wrote:

> 
> 
> On Sat, Jul 14, 2012 at 12:35 AM, Pat Hayes <phayes@ihmc.us> wrote:
> Alan has drawn my attention to this thread., which I confess I find rather confusing.
> 
> I've used the "i'm confused" thing too. But I doubt you are. It's perfectly normal for the chair of one group, on seeing a change in a specification on which it depends, trying to figure out what the implications are for their spec. Second, David showed a misunderstanding of what the situation was from a logical point of view, and this made me worry that others (even the editors of the RDF 1.1 spec) might also share such misconceptions.

Perhaps 'puzzling' would have been better. I really was, no rhetoric involved. 

>  
> First, some basics. Regarding skolemization, it is important to remember that skolemization is not a valid inference process, strictly speaking. If you start with a graph G contaning a bnode and skolemize it to get another graph GS where the bnode has been replaced by a URI, then G does not entail GS.
> 
> Good. That's important, as it means that the RDF document needs to specify in which situations, and with what consequences, skolemization may be done.

It MAY be done at any time. The RDF specs do not set out to say what may or may not be done to RDF. You are free to do anything you like. What the specs do specify is what changes to RDF graphs are valid entailments. Skolemization is not a valid entailment. It is very close to being valid, but it is not strictly valid. 

>  
> The relationship between them is subtler: it is that: **if H does not contain the skolem URI **, then G entails H iff GS entails H. Now, GS entails GS, if course, so you might think that this implies that G entails GS, but it doesnt because GS of course *does* contain the skolem URI.
> 
> It can't by what was specified - that the skolem URI should not appear anywhere else.

But it does appear in the skolemized graph GS, by construction. That is why we call it 'skolemized'. 

>  
> So, it is not at all surprising that the skolemization of a graph might have logical properties that are not shared by the unskolemized graph. Such a situation does not break RDF entailment, nor does it render skolemization impossible. It just means that you have to use skolemization carefully, as it is not a valid inference mode all by itself; but this always was the case.
> 
> I will re-read the draft spec to see how this is stated.
>  
> As to the OWL mappings. This is one instance of a general phenomenon, that when a 'higher' language (OWL-DL) is embedded into RDF, there are going to be restrictions on the legal forms that are used to encode the higher language. You will not get perfect freedom to perform even valid RDF entailments on the OWL-DL/RDF without risking making the RDF into something that is no longer a legal RDF encoding of OWL-DL syntax.
> 
> Agreed for OWL2 under the DL semantics. However OWL according to the RDF semantics is a different story and that is part of the spec I worry about too. 
>  
> Put another way, the OWL-DL imposes its own syntactic and semantic retrictions which go beyond those imposed by RDF itself, and engines which need to use the OWL-DL/RDF *as OWL-DL* must be able to respect those OWL-DL-imposed restrictions.
> 
> It is not only engines that may need OWL-DL/RDF, but users of those engines. A sanction for engines to do skolemization at will will affect those users inadvertently. Sometimes triple stores are used solely to *store* OWL.

And it would be dangerous to skolemize such stores, for fear of brealking the OWL conventions. Forgive me, but this seems *obvious*, so I wonder why you are making such a big deal out of it. I must be missing something that you are assuming, or something (?)

>  
> This is hardly surprising. The "Full" subfamily is there for people who wish to have complete freedom at the RDF level, but they necessarily pay the price of sacrificing deductive efficiencies available only for the more restricted higher-level language.
> 
> Yes, but they also define OWL using the RDF Semantics as a semantic extension of RDF (as it existed when the spec was finalized). Changes thereafter that change RDF semantics will, and should be, examined carefully.

Indeed. So far, nobody (except me) has suggested any changes in the RDF semantics, partly for this reason. 

>  
> So, overall: nothing here is particularly surprising or alarming, and nothing is (any more) broken (than the world has always been.)
> 
> I'm not so sure. For example, looking at the current draft we see.
> 
> 
> "Blank nodes do not have identifiers in the RDF abstract syntax. The blank node identifiers introduced by some concrete syntaxes have only local scope and are purely an artifact of the serialization."
> 
> It is incorrect that blank notes are purely an artifact of serialization. In *any*  serialization that I am aware of. Please correct me if I am wrong.

The blank node *identifiers* are artifacts of the serialization. In the RDF abstract syntax, blank nodes have no identifiers. 

> 
> Then:
> 
> "In situations where stronger identification is needed, systems may systematically transform some or all of the blank nodes in an RDF graph into IRIs [IRI]. Systems wishing to do this should mint a new, globally unique IRI (a Skolem IRI) for each blank node so transformed."
> 
> This amounts to, from my point of view, entailing

No, it does not say that that this change is an entailment. However, I agree that this wording  could be misleading, and perhaps we should make the situation clearer. 

> : systems may systematically change OWL ontologies (under the DL-semantics) stored in them to become RDF that is no longer an OWL (under the DL semantics) ontology. 
> 
> That sounds bad to me. It definitely sounds more broken then things were before. Before I could put an OWL ontology into a named graph and get it out unscathed. Now I can't count on that.

If all you do is put it in and then take it out, it will be unscathed. If someone makes a change to the graph while it is in there, it might get changed, yes. That includes skolemizing it. 

> 
> "This transformation does not change the meaning of an RDF graph, provided that the Skolem IRIs do not occur anywhere else."   
>  
> This also seems just wrong. Under what sense of "meaning" would this be true? You say above that this operation is not a valid inference model. 

We went around in circles on this wording. We needed an intuitively acceptable form of words which could be understood by people who cannot follow formal semantics, which conveys the basic idea. The sense of "meaning" is that the skolemized graph entails the same things as the original graph does, *provided* they don't contain the skolem URI. So the skolemized graph has the exact same, one might say, inferential capacity as the original graph, provided we are only testing it against graphs which do not contain the skolem URI. 

> 
> "Systems may wish to mint Skolem IRIs in such a way that they can recognize the IRIs as having been introduced solely to replace a blank node, and map back to the source blank node where possible."
> 
> Where would it not be possible? 

Almost always. I would prefer to not have this particular wording in the spec, as it is logically meaningless. 

> Wouldn't this "feature" better be specified as part of the SPARQL specification?

There is a strong contingent of 'linked data" enthusiasts who want RDF to be blank-node-free, and this skolemization stuff is there partly to keep them (and the developers who make tools for them to use) happy. 

By the way, skolemization was mentioned in the 2004 RDF specs, so its not exactly something new. 

> There you could say that given some keyword, blank nodes in the result should be skolemized, and that subsequent queries which retrieve the same blank nodes, asking them to be skolemized, MUST get the same skolems back each time.
> 
> Sanctioning such changes for any process that handles RDF looks to me to be a bad idea.

I agree. I dont think that anything is being "sanctioned" in the sense that it can be done without any attention to the consequences. Even performing a valid inference might change a graph in a way which interferes with some engines (such as an OWL parser).

Pat

> 
> I'm happy to hear explanations of how I am wrong in each case I list above - I'm anxious to learn. But let's stay away from the "I'm confused" rhetoric, please.
> 
> -Alan
> 
> 
> 
> On Jul 13, 2012, at 1:03 PM, Alan Ruttenberg wrote:
> 
> >
> >
> > On Fri, Jul 13, 2012 at 1:47 PM, David Booth <david@dbooth.org> wrote:
> > On Fri, 2012-07-13 at 13:08 -0400, Alan Ruttenberg wrote:But that would render skolemization impossible, and it would conflict
> > with the treatment of blank nodes as existentially qualified variables
> > http://www.w3.org/TR/rdf-mt/#unlabel
> > since it would be like saying "there exists an x, but you're not allowed
> > to name x with a URI".
> > >
> >
> > It would be like saying, you can't change an expression "there exists an x" to "x". They don't mean the same thing. If you have "y" then it implies there exists an x. But it doesn't imply "x". Blank nodes, according to the RDF semantics, mean "there exists an x".
> >
> > As such, it would seem to break RDF entailment.
> >
> > And if this is correct I would expect there to be a formal objection to the proposal.
> >
> > Perhaps Micheal could shed some light.
> >
> > -Alan
> >
> >
> > --
> > David Booth, Ph.D.
> > http://dbooth.org/
> >
> > Opinions expressed herein are those of the author and do not necessarily
> > reflect those of his employer.
> >
> >
> 
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
> 
> 
> 
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 15 July 2012 02:52:39 UTC