Re: OWL2 RDF mapping and skolemization [was Re: OWL equivalentClass question]

[Copying the OWL2 comments list]

Hi Alan,

So to close the loop on this, could an erratum be added to the
RDF-->OWL2 mapping spec
http://www.w3.org/TR/owl2-mapping-to-rdf/ 
to address this gap?  Either by: (a) loosening the RDF-->OWL2 mapping
rules to allow bnodes or IRIs wherever bnodes are currently required; or
(b) explaining that IRI=>bnode entailment (as explained by Pat Hayes
below) may be required before applying the rules, but an implementation
of the mapping rules can effectively perform that entailment on the fly
by permitting bnodes or IRIs in those locations where bnodes are
expected.  For future implementers I think it's important to have such a
note associated with the spec, so that the point isn't just buried in
the email archives.

BTW, I think it's important to note that this is *not* merely a
skolemization issue, though skolemization certainly highlights it.  This
issue can arise whenever RDF is generated with the intent to have OWL2
semantics, such as in Nathan's original example.

Thanks,
David

On Sun, 2012-07-15 at 23:26 -0500, Pat Hayes wrote:
> On Jul 15, 2012, at 10:32 PM, David Booth wrote:
> 
> > On Sun, 2012-07-15 at 21:48 -0500, Pat Hayes wrote:
> >> On Jul 15, 2012, at 9:17 PM, David Booth wrote:
> > [ . . . ]
> >>>> 
> >>>> But beyond that, it should always be possible to *add* information to an
> >>>> RDF graph that contains OWL2 encodings, and still have those encodings
> >>>> be recognized when mapping back from RDF to OWL2.
> >> 
> >> One has to be careful what exactly is meant by 'adding information".
> >> Skolemizing adds some triples but deletes some other triples (the ones
> >> with the bnodes in them.) They can be restored by a valid entailment,
> >> so in a sense the "information" is still there in the graph, but they
> >> are missing from the skolemized graph, and this means that said
> >> skolemized graph may fail to have some syntactic properties that the
> >> original graph had, such as being conformant to the OWL/RDF specs for
> >> a correct RDF encoding of some OWL. 
> > 
> > That sounds exactly right to me.  
> > 
> > So it sounds like the gap at present is that the current RDF-->OWL2
> > mapping rule is a little too rigid in requiring a blank node in that
> > position
> 
> Yes. I guess I don't know what the reasoning was behind this decision,
> but I can see one way to justify it.  If we are considering the
> mapping OWL -> OWL/RDF, then it makes sense to use bnodes in all these
> positions, since the mapping only requires that the relevant things
> exist, and to use an IRI would potentially introduce irrelevant side
> issues. But now we might also want to require that the inverse mapping
> OWL/RDF -> OWL be defined so that it is a genuine inverse of the first
> mapping, to ensure that the round-trip composition works correctly
> both ways around. As I say, I do not know for sure if this was the
> reason, but it would certainly make sense. I would have voted for this
> way of writing the standard, given this argument.
> 
> > , and this forces the user to perform the (trivial) entailment
> > that you mention above (to add blank nodes back into the graph) if
> > skolemization has been performed, in order to impart the syntactic
> > properties that the rule expects. This does not mean that the existing
> 
> > RDF-->OWL2 mapping rule is semantically wrong, but it means that the
> > rule is not as user friendly as it could/should be, because it requires
> > the user to perform that entailment for the rule to work: essentially,
> > adding a corresponding bnode for every IRI in the graph.  
> 
> Or else, in practice, to just apply the inverse mapping to the graph
> with IRIs, in spite of it being technically incorrect to have IRIs in
> those positions rather than bnodes. Which saves the step of generating
> the technically legal bnode version, just to satisfy the letter of the
> spec. 
> 
> Pat
> 
> 
> > 
> > 
> > 
> > -- 
> > 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
> 
> 
> 
> 
> 
> 
> 

-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Tuesday, 17 July 2012 14:47:44 UTC