Re: Review of Entailment Regimes (Action-317)

On 1 October 2010 11:26, Ivan Herman <> wrote:
> 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, I think it would be a good idea to turn all those into links; after all, all those URI-s are dereferencable...)

done (only the rif-imports URL is not turned into a hyperlink since it
is not even clear yet whether this will be renamed or not)

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

not done, I leave this up to Chime

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

I also think that the current condition is nicer and I would like to
keep it, but I am a bit concerned that this might not be what people
actually implement, so I think asking for feedback could help us to
judge whether we suggest something that just won't be accepted out in
the wild.

> The document looks really good!


Thanks for the coments,

> Thanks
> Ivan
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home:
> mobile: +31-641044153
> PGP Key:

Dr. Birte Glimm, Room 309
Computing Laboratory
Parks Road
United Kingdom
+44 (0)1865 283520

Received on Saturday, 2 October 2010 18:01:29 UTC