draft review of rif-rdf-owl

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