review of rif-rdf-owl

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.

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.

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


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


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.


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


Jeremy

Received on Tuesday, 13 May 2008 11:57:38 UTC