W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > March 2003

Re: comment horrocks-01

From: Frank Manola <fmanola@mitre.org>
Date: Wed, 12 Mar 2003 17:19:57 -0500
Message-ID: <3E6FB28D.8060305@mitre.org>
To: pat hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org, Ian Horrocks <horrocks@cs.man.ac.uk>

pat hayes wrote:

> I think we need to pay some attention to this. This request reflects an 
> energetic exchange of views within Webont, and although it did not 
> emerge as a consensual group comment, it clearly reflects a very deep 
> issue for some potentially large user communities for RDF.

I agree we need to pay some attention to this (I remember thinking that 
when Ian first made the comment), but I need some clarification of the 
pros and cons.

> The issue is that the only available syntactic form for adding comments 
> to RDF involves making RDF assertions, since rdf:comment is a genuine 
> RDF property, so all such triples have genuine entailments. This means, 
> in particular, that changing a comment in an ontology changes the formal 
> entailments made by that ontology, so is a genuine logical change to 
> that ontology. Whether or not this should be considered a bug or a 
> feature is controversial, but there is no doubt that to those for whom 
> it is a problem, it is a very serious and basic problem, something very 
> close to a fatal can't-live-with objection to RDF.

In Ian's message, he said "In particular, it would be inappropriate for 
*applications* to infer semantic differences in information represented 
in two ontologies based solely on differences in comments (in the same 
way that it would be inappropriate for code to behave differently when 
only the comments are changed)." [my emphasis]

I'm having problems with who is doing the inferring/entailments in 
question, and what kinds they are.  It makes perfect sense for an 
*application* to decide that it wants to pay no attention to triples 
with rdf:comment properties, but it seems to me what we're being asked 
to do is to rule that out in some sense for *all* applications, by 
making this somehow basic in RDF.  If triples with rdf:comment 
properties are "pure comments", presumably they are still there in the 
graph [otherwise the XML comment option would have worked], but they are 
ignored in certain types of processing.  I would hope that I could still 
write an application that, say, used the number of comments (and maybe 
even the length of the values) to decide whether an ontology was 
"well-commented" in some sense?  So could you give me some test cases 
describing the sorts of entailments in RDF that you'd like to forbid 
(test cases describing the situations below, which I didn't entirely 
understand, would be fine).

> It also means that one can set up inference chains which are probably 
> not what any rational person would want to do, eg by defining an 
> rdfs:subPropertyOf rdf:comment and then expecting to be able to use that 
> to infer that something is an rdf:comment value. This distinction isn't 
> particularly important (IMO) in RDF itself, but it becomes more 
> trenchant in OWL, where quite subtle and indirect chains of reasoning 
> could, in principle, allow one to draw unexpected  (and probably 
> unintended) conclusions about an rdf:comment value, eg by virtue of 
> there only being three comments in the graph, a cardinality constraint 
> applying to a superproperty of rdf:comment and an assertion that 
> rdf:comment was functional could produce an inconsistency, or maybe 
> allow one to conclude that an invisible comment must exist even though 
> it is not in the graph. (The ambiguity in what this would really mean 
> illustrates one of the aspects which I think most bothers Ian and 
> others, which is that this treatment of rdf:comment muddles the 
> distinction between the logical content of an RDF graph and what might 
> be called the syntactic decorations of it, and hence muddies the 
> semantic clarity of the language by importing things - in the case, 
> comment values - into the semantic domain which do not belong there. 
> Personally I am happier in muddier semantic waters than Ian is, but I 
> recognize that his views are widely shared.)

This seems similar to the class/instance distinction, which RDF also 
"muddles", because at this level we don't want to wire those 
distinctions in.

> We could address this in various ways (dark triples, anyone?), but all 
> but one of them are too ambitious at this stage, probably. One thing we 
> could do relatively easily is for the MT to declare that all 
> interpretations make all assertions of rdf:comment true. This in effect 
> would cancel the entailments which bother Ian. What this amounts to in 
> practice is that all comments are trivially entailed, so one cannot use 
> entailment as a guide to associating a comment with a graph; one has to 
> appeal to a more directly syntactic criterion, such as actually being in 
> the graph.

That sounds reasonable, assuming I understood what these extra 
entailments are that create the problem (see the "test cases" comment 

> On the other hand, this might bother some other users who would prefer 
> to use entailment as a general RDF 'glue', even for such things as 
> comments.
> An alternative point of view is that problems will only arise if people 
> fiddle with the machinery (which is forbidden in OWL-DL in any case), 
> and that Ian's worries about development of large ontologies can 
> probably be handled by providing some extra-RDF way of associating 
> developer comments with RDF graphs, eg by adding non-RDF XML markup. 
> This is rather a brush-off attitude, however, particularly if we do not 
> actually provide any hints as to how this might be done.
> Comments? Is there any other way to allow for 'genuine' comments in an 
> RDF graph?

Reification anyone?


Frank Manola                   The MITRE Corporation
202 Burlington Road, MS A345   Bedford, MA 01730-1420
mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-875
Received on Wednesday, 12 March 2003 16:59:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:21 UTC