- From: Jeremy Carroll <jjc@hpl.hp.com>
- Date: Tue, 06 May 2008 18:14:57 +0100
- To: www-archive@w3.org
This is a draft review of http://www.w3.org/TR/2008/WD-rif-rdf-owl-20080415/ I hope that a few of these comments will be endorsed by the OWL WG, who asked me to review. The others I will make as personal comments, (or perhaps as HP comments). 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. Section 1. 3) para1 editorial Suggest change 'must be' to 'are' It is possible to give whatever interpretation one wants, 'must' suggests some sort of conformance, but there is no framework for conformance provided. 4) para5, editorial I found this paragraph read badly. Suggest rephrasing like: [[ A specialization of this scenario is the publication of RIF rules that refer to RDF graphs: publication is a special kind of interchange: one to many, rather than one to one. When a rule publisher A publishes its rules on the Web, it is hoped that there are several consumers that retrieve the RIF rules and RDF graphs from the Web, translate the RIF rules to their own rules languages, and process them together with the RDF graphs in their own rules engine. The use case Publishing Rules for Interlinked Metadata (RIF-UCR) illustrates the publication scenario. ]] 5) editors note, end of section 1, opinion I suggest you do not consider RDF entailment, the others are more interesting. 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. 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 ... 8) end of para, under table 1, question Does the sentence [[ This means that whenever a triple s p o is satisfied, the corresponding RIF frame formula s'[p' -> o'] is satisfied, and vice versa. ]] adequately take account of CWA and OWA divergences between the frameworks? 9) Discussion of ill-typed literals, change I suggest deleting the bulk of this discussion including examples from [[ Typed literals in RDF ]] down to [[ the datatype xsd:integer. ]] I think a simple statement like: [[ RIF is not intended to interoperate with the rarely used facility of RDF to permit ill-typed literals. ]] would be better. This extended example gives much too much weight to an RDF 'feature' that is there more for allowing legacy systems to not implement datatyping than as a forward looking functionality. 10) 2.1.1 the word 'infinite', comment Ah, you know RDF Concepts better than I do, I had to go and check that this was correct! (I was amused) 11) 2.1.2 para1, change I suggest delete of the sentence [[ Furthermore, RDF allows expressing typed literals for which the literal string is not in the lexical space of the datatype; such literals are called ill-typed literals. ]] it unnecessarily labours an uninteresting point. 12) 2.1.2 defn of conforming datatype map, change I suggest not using the term 'symbol space', but try using more familiar term, such as 'name from the RIF namespace' 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. 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 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. 14) 2.1.2 Last enumerated list, bug There is an error here. Conditions 1 and 3 contradict one another. 15) 2.2.1 general comment, opinion I am not sure that covering simple entailment is worth it. I am not convinced that it isn't either. The problem for me is the added point of confusion of (IR union IP) versus IR elsewhere. Looking at this text makes me think that RDF Core should have required IP subset IR, also for simple interpretations. As is the extra text required for this point is a cognitive load on the reader, and the RIF WG needs to be sure that the additional cognitive load is worth the benefit of supporting simple entailment. It probably is, but then again ... 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? 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 ... 17) 3, last para before 3.1, change [for OWL WG to consider - will not be a personal comment] I suggest replacing the sentence [[ This paves the way towards combination with OWL 2, which is envisioned to allow punning in all its syntaxes. ]] and the sentence from 3.2.2.3 [[ It is currently expected that OWL 2 will not define a semantics for annotation and ontology properties; therefore, the below definition cannot be extended to the case of OWL 2. ]] with a less definitive statement such as: [[ In this document, we are using OWL to refer to OWL1. While OWL2 is still in development it is unclear how RIF will interoperate with it. At the time of writing we believe that with OWL2 the support for punning may be beneficial, and that there might be particular problems in using section 3.2.2.3. ]] 18) 3, editors note, opinion I would put this either in the acknowledgements or as a note in the document at this point. I am strongly in favour of appropriate citations. 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? I am wondering whether there are possible RIF/OWL DL combinations that would be unfortunate for OWL DL implementors ... 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. 21) 3.2.2.3 see comment 17 I hope these were helpful, and I didn't get too upset about the rif:iri rif:text thing! Jeremy
Received on Tuesday, 6 May 2008 17:16:30 UTC