W3C home > Mailing lists > Public > semantic-web@w3.org > July 2012

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

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 17 Jul 2012 13:53:08 -0500
Cc: David Booth <david@dbooth.org>, Michael Schneider <schneid@fzi.de>, semantic-web@w3.org, nathan@webr3.org, "Peter F. Patel-Schneider" <pfpschneider@gmail.com>
Message-Id: <18577F8D-E82F-4DB3-A000-60D6FF5565A1@ihmc.us>
To: Alan Ruttenberg <alanruttenberg@gmail.com>
((Opinions expressed here are my own. This is not an official response from any WG.))

On Jul 17, 2012, at 11:12 AM, Alan Ruttenberg wrote:

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

With respect, the role of the OWL WG here is to react to the design of RDF as determined by the RDF WG, rather than as it might be determined by your views on how RDF should be designed. OWL compatibility is one issue among many that needs to be considered by the RDF WG. 

> 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 disagree.  Skolemization is not in any sense a change to the semantics of RDF. And, whether you like it or not, skolemization (or some equivalent process for removing blank nodes) is going to be widely done. Several deployed RDF tool suites already do this, in effect. So whether we think of it as a flaw or as a feature, making OWL incompatible with it for no reason other than conservatism seems wrong-headed. Particularly as, from the purely semantic perspective, there is no actual reason for requiring blank nodes rather than skolem URIs in these mappings. 

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

Mentioning skolemization is not a change to RDF, "proper" or otherwise. 

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

This matter has been discussed, and (speaking here informally and purely for myself, but...) I believe the consensus of opinion in the RDF WG is that this is not a serious objection to the use of skolemization in RDF practice, particularly given the recommendation to use a standard 'anonymous' URI scheme to indicate that skolemization has taken place. 

> Shall we now cause there to be a
> "samebnodeas.org" site too?

No, and there would be no need for one. 



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

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 Tuesday, 17 July 2012 18:53:44 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:48:38 UTC