Re: Review of Entailment Regimes (Action-317)

On Sep 22, 2010, at 19:17 , Birte Glimm wrote:

> Hi Olivier,
> thanks for the review. I comment inline.
> 
> @Chime: I also updated the RIF part since Olivier had just syntactical
> and easy to do comments for that section.
> 
> I also read the document again myself an made a couple of other
> changes (nothing major). I meant to do that earlier, but didn't find
> the time :-(

And I looked at the latest version and have some more comments...

-----
General comments: Editorial notes are there to draw attention of the community at large at various possible alternatives. However, I do not think we should keep them forever. Eg, the editorial note on the alternatives on the RDF entailment (right before section 3) is now a year old, and the community had ample time to react on the design alternatives described there (which it did not...).

Bottom line: I would propose to remove any editorial note that is older than, say, 6 months... The only exception is the one in 7.1, because the exact URI for rif:imports is still pending.

------

There are several occurrences of the URI-s used for entailment and profiles (eg, http://www.w3.org/ns/entailment/Simple). I think it would be a good idea to turn all those into links; after all, all those URI-s are dereferencable...)

------

There is a sudden jump in the complexity of the examples when getting to the RIF core. I wonder whether it is possible to add a simpler example here...


Comments on your comments, too:

[snip]

> - At the end of Section 2.2 I added an editorial note, which suggests
> an alternative C2 condition that basically forbits terms of the form
> rdf:_n as bindings. I am a bi concerned that if you want to implemen
> the regime via a set of materialisation rules, then at the moment, you
> have to look for which n the terms rdf:_n occur in the graph and for
> all those you add the axiomatic triples. This seems hard to do with a
> set of pre-defined rules that is independent of the input. If you
> would use the alternative, materialisation rules do not have to care
> for which n a term rdf:_n occurs in the input. I think it might be
> useful to point this out and maybe get some feedback from implementors.

Yes, I understand the difficulty, having done some experimental rule based implementation of Horst myself some time ago. Indeed, the engine has to have a special branch that, for example, looks at the maximum 'n' for rdf:_n (Horst's condition was a bit more liberal than what we have). But I am, nevertheless, a bit wary about this alternative because, to use the example in the document, the user's expectation would clearly be to get rdf:_n back as an rdf:Property. I am not sure we should optimize on the implementation here (clearly, it _can_ done by an implementation, it is just a pain in the neck...)

The document looks really good!

Thanks

Ivan


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf