Response to JC2

Dear Jeremy,

This is a response to your second e-mail with comments on the RIF RDF and compatibility document [1]. I left out the comments that were addressed in your previous e-mail [2].

> This is a review of
> http://www.w3.org/TR/2008/WD-rif-rdf-owl-20080415/
> 
> These are my personal comments.
> A few comments from the OWL WG should follow soon.
> 
> In addition to the draft comments you may have already seen, and which I 
> include below, I had three additional comments:
> 
> A) I am supportive of the notion of generalized graph, and would be 
> happy to help provide arguments why this is appropriate in this context, 
> rather than using an RDF graph from RDF Concepts.

We are glad to hear that you are supportive of this notion. Do you have further arguments besides those mentioned in endnote 1?

> 
> B) I am told that rdfs:subPropertyOf and rdfs:subClassOf do not have an 
> RDFS like semantics in RIF ... I don't recall seeing any mention of 
> these in the document, and wondered whether any 'health warnings' are 
> needed. For example, the special treatment of rdf:type presumbably 
> doesn't apply to subProperties of rdf:type, and for people using say
> 
> my:type rdfs:subPropertyOf rdf:type .
> 
> this would presumably cause problems.

When considering RDFS entailment, RIF-RDF combinations have exactly the RDFS semantics for rdf:type and rdfs:subclass. The misconception of those who told you about the discrepancy most likely comes from the fact that RIF includes its own class membership and subclass constructs, and namely # and ##. The semantic conditions on common RIF-RDF interpretations (section 2.2.1.2) ensure that there is interoperation between the RDFS and RIF notions, respectively, but when using the RDFS notions, the semantics of RDFS applies.

Does this verify the issue? Do you feel that any explanation should be added to the document?

> 
> C) My concern about ^^rif:iri and ^^rif:text below is entirely 
> presentational. I can see the aesthetic appeal of a uniform treatment in 
> the formal treatment of symbols that they all are mapped by a mapping 
> function. This does not, in my view, need to be made explicit except in 
> the formal semantics ...

It has been decided to use Turtle-style shortcut syntax for IRIs in the document; this should address some of your concerns. In addition, we will add an explanation (see [3]) about the correspondence between plain literals with language tags in RDF and constants in the symbol space rif:text in the document; the working group found that there is not enough justification for adding specific shortcut syntax for strings with language tags.

> 1) Overall:
> 
> This reads as a mature and complete document, and it is
> plausible to have last call soon.
> It's main failing, if one can call it that is that
> at times it is a little too detailed, and gives too much
> attention to uninteresting details.
> 
> 2) Scope of review
> 
> I reviewed the document excluding the Appendices.
> 
> I have not read the other RIF documents, so am not competent
> to review the interaction between this document and RIF.
> 
> I am not competent to review a few of the technical sections
> to do with DL: specifically 3.1.1 and 3.2.2.1, (and more generally
> 3.2.2) were overly challenging for me, and this should not be
> seen as a criticism of those sections.
> 
> ==
> 
> Specific comments follow - I distinguish three types of comments
> 
> editorial/bug/change/opinion/question
> 
> to aid in the processing of these comments.
> The 'change' comments are where I would prefer the document
> to be changed, but there may be arguments the other way.
> The others are meant to be uncontroversial!
> 
> The 'opinion' comments are like 'change' but of lower force,
> i.e. ignore me, I don't mind.
> 
> 
> The comments are made in document order.
> 
> 
> 5) editors note, end of section 1, opinion
> 
> I suggest you do not consider RDF entailment,
> the others are more interesting.

Your opinion is noted. However, we feel that there is not enough justification, at this point, to remove the treatment of RDF entailment.

> 
> section 2
> 
> 6) Table 1 (and in general), change
> 
> I am not impressed with "literal string@en"^^rif:text
> I suggest changing this to "literal string"@en
> 
> Rationale: the convention for displaying such items is well-established,
> and it introduces spurious and unnecessary confusion to readers familiar
> with such conventions not to follow it.

I refer here to our reply to comment C above.

> 
> 7) general comment, change
> 
> I am also not impressed with rif:iri
> 
> I suggest change of "a"^^rif:iri for <a>.
> 
> Otherwise this also provides unnecessary confusion. For example, what is
> the relationship between rif:iri and xsd:anyURI? I see in the Wiki that
> it is none, but it feels like an unmotivated new way of writing down a
> URI ...

I refer here to our reply to comment C above.

> 13) 2.1.2 defn of conforming datatype map, change
> 
> Requiring rif:text in the datatype map is well-wierd.
> 
> a) rif:text is not a datatype.
> It is not defined anywhere much, the best I could find was on
> http://www.w3.org/2005/rules/wiki/DTB
> with the text
> [[
> This symbol space represents text strings with a language tag attached.
> The lexical space of rif:text is the set of all Unicode strings of the
> form ...@LANG, i.e., strings that end with @LANG where LANG is a
> language identifier as defined in [RFC-3066].
> ]]
> which doesn't merit review time.

It has been decided that a new recommendation-track document for this datatype will be created jointly by the RIF and OWL working groups.

> 
> b) it is wholly unclear why rif:text should be a datatype and rif:iri is
> not, they both seem to be cases of NIH

rif:iri is not a datatype, because IRIs are (as in RDF) symbolic, i.e., they do not have a fixed interpretation. Symbols in datatypes all have fixed interpretations.

> 
> c) it seems that this definition is used in the notion of D-satisfiable
> in section 2.2.2. It is not plausible that an RDF implementation will
> implement such a 'datatype', even if it were adequately specced, (since
> it duplicates RDF functionality and would cause confusion) so the
> definition is made worthless.

Firstly, exactly because the data type duplicates RDF functionality, we feel that it is not a burden for RDF implementations to implement this datatype. Second, rif:text is a required data type in RIF, which means that all implementations of RIF-RDF combinations need to implement this datatype anyway. Finally, most importantly, since rif:text is a datatype used in RIF-RDF combinations, we feel that it should be treated as a datatype, and thus subject to the D-entailment semantics for datatypes.

> 16) 2.2.1.2 last example concerning conditions 5 and 6, comment
> 
> This ^^rif:iri stuff is confusing, can't you change it to something more
> familiar?

I refer here to our reply to comment C above.

> 
> The sentence in the Wiki:
> [[
> A rif:iri constant must be interpreted as a reference to one and the
> same object regardless of the context in which that constant occurs.
> ]]
> and the exclusion of rif:iri from conforming datatype maps, suggests
> that you aware that this things get treated differently from datatypes.
> 
> Sorry I seem to be saying the same thing again ...

Does our answer to comment C above address your concern?

> 19) 3.1, para2, question
> 
> [[
> Specifically, the only terms allowed in class and property positions in
> frame formulas are constant symbols.
> ]]
> 
> does this interact OK with the syntactic restrictions that define OWL DL?

This restriction has been specifically designed to interact with OWL DL in an appropriate manner. Specifically, it disallows quantifying over classes and properties. The semantic conditions on common RIF-DL interpretations (section 3.2.2.2) ensure that the separation of the vocabulary required in OWL DL interpretations applies to the combination as well.

> I am wondering whether there are possible RIF/OWL DL combinations that
> would be unfortunate for OWL DL implementors ...

Yes, there are. For example, if function symbols are used or if rules are not DL-safe. We have included a definition of DL-safeness in section 3.1.1, which is a syntactical restriction on the use of variables in rules. We conjecture that function-free DL-safe rules meet the requirements for OWL DL implementers.

> 
> I may simply not have understood this text enough. If you are happy that
> the answer to my question is that I have misunderstood that's OK.
> 
> 20) 3.2.2.1 first definition, question
> 
> I did not understand this section, not being the target audience.
> However, I wondered whether "if a!=IC(rdf:type) then b in Dind" was what
> was intended. It didn't quite feel right, but then I am picking at
> something without having understood properly.
> 
> "yes - it is right" would be the ideal response.

yes - it is right

> I hope these were helpful, and I didn't get too upset about the rif:iri
> rif:text thing!

your comments were very helpful. Thank you very much. And, don't worry, we did not feel insulted :-)

Best, Jos on behalf of the RIF working group.

[1] http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0003.html [2] http://lists.w3.org/Archives/Public/public-rif-comments/2008May/0002.html [3] http://www.w3.org/2005/rules/wiki/SWC#Symbols_in_RIF_Versus_RDF.2FOWL_.28Informative.29