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

On Tue, Jul 17, 2012 at 10:39 AM, David Booth <david@dbooth.org> wrote:
> [Copying the OWL2 comments list]

I'm removing the public-owl-comments from my reply as my response here
is not in any official capacity. It represents my opinion. I expect
that there will be an official response to your request later.

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

We'll see what the group says. It would represent a fairly big change
and the sole reason the OWL WG is still active is to wait for the XML
schema group to finalize the documents we depend on.

Frankly, I also see the current skolemization proposal as a bad design
both from a technical and technosocial point of view, and so my
opinion at the moment would be that such a request be denied.

On the formalities, I see two charter issue.

1) This represents a backwards compatibility issue and the charter
says: "Care should be taken to not jeopardize exisiting RDF deployment
efforts and adoption. In case of doubt, the guideline should be not to
include a feature in the set of additions if doing so might raise
backward compatibility issues."

2) Listed as out of scope: "Changing the fundamentals RDF(S) semantics
(e.g., usage of model theoretical semantics, interpretation of blank
nodes). Note that minor improvements may be required by some of the
work in the scope of the Working Group, which is still in the scope of
the work.". The proposed change seems to violate that. I don't see it
as a minor improvement - rather as adding a flaw.

In addition I consider the change unjustified from a technical point
of view and should functionality similar to this be desired, consider
that it would better be accomplished without changing the RDF
specification. I have given an example of how this could be
implemented as a SPARQL feature and therefore completely under use
control, and without requiring changes to RDF proper.

I see positive damage from the change as people try to deal with bnode
authored RDF that travels through two processing paths that distinctly
skolemizes the same bnodes. Shall we now cause there to be a
"samebnodeas.org" site too?

Regards,
Alan

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 16:13:54 UTC