This is a response to your 1st e-mail with comments on the RIF RDF and compatibility document . Thank you very much for your very helpful comments. Find our responses in-line.
> 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.
We hope that we have sufficiently addressed this concern. We have addressed your detailed comments related to uninteresting details. If there are any uninteresting details left, please let us know.
> > 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 126.96.36.199, (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.
will be implemented in the next draft
> > 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. > ]]
will be implemented in the next draft
> > > 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?
There is no such divergence between the frameworks. RIF-BLD has a standard first-order-like multiple-model semantics, so there is no closed world assumption in the semantics.
Is there something in the document that implies that RIF has the CWA?
> > 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.
We agree that the description of ill-typed literals in the introduction to section 2 should be removed. In fact, we do not think it is necessary to mention them at all here. We decided to keep the example, but remove the ill-typed literal. We think the example is important to understand how blank nodes are dealt with in combinations.
> > 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.
the senses will be removed.
> > 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'
"symbol space" is a concept used in RIF that generalizes datatypes. In the formal definitions it's necessary to refer to this concept.
> > 14) 2.1.2 Last enumerated list, bug > > There is an error here. Conditions 1 and 3 contradict one another.
this is indeed an error. Condition 3 will be removed.
> > 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 ...
We agree that RDF Core should have required this subset relationship. As it has not, we will have to live with this cognitive load, as there is interest in simple entailment.
> > 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.
We will add a citation to the overview section (1).
We hope that we have the addressed your comments to your satisfaction. If you have any further comments/discussion, please let us know.
Best, Jos on behalf of the RIF working group