From: Jos de Bruijn <debruijn@inf.unibz.it>

Date: Mon, 01 Jun 2009 11:21:53 +0200

Message-ID: <4A239DB1.2060202@inf.unibz.it>

To: Axel Polleres <axel.polleres@deri.org>

CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Date: Mon, 01 Jun 2009 11:21:53 +0200

Message-ID: <4A239DB1.2060202@inf.unibz.it>

To: Axel Polleres <axel.polleres@deri.org>

CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Axel, Thanks for the review. Below my responses to the comments that I did not implement as-is: > Section 1: > ========== > > > * "A consumer of the rules retrieves the OWL ontology and translates > the ontology and document into a combined ontology+rules description > in its own rule extension of OWL." > > It is a bit unfortunate that this import in only unidirectional. > It may be worthewhile (though maybe too late) to ask the OWL WG > whether they would consider a simlar import mechanism on their side > for RIF rules. This way they could e.g. refer to DL-safe RIF rulesets > from OWL ontologies. I didn't check the OWL documents yet, but the > ycould simply accomodate for this by referring to SWC. This is an issue for OWL; not the SWC document. > Section 3: > ========== > > * "containing types literals" > --> "containing typed literals" I could not find this one. > Section 3.1 > =========== > > * Section 3.1.2 > "A RIF-RDF combination consists of a RIF document and zero or more RDF graphs" > > Why do we allow only 1 RIF dcoument and arbitrary RDF graphs in a > combination? Because an RIF document an import any number of RDF graphs. > Section 3.2 > =========== > > * 3.2.1.1 > > * Section: 3.2.1.3 > > * "I is a semantic multi-structure [...] " > > weren't muli-structures denoted by \hat{I} in BLD/FLD? I suggest in > order to use consistent notation, you use \hat{I} to denote the whole > multi-structure, whereas you use I to denote the common part only: > > "Given a semantic multi-structure \hat{I}={I1, ..., In}, we use the > symbol I to denote the common part of the individual structures I1, > ..., In. In the following, we will - slightly simplifying - also refer > to I as a multi-structure, meaning only this common part of \hat{I}." > > Would that make sense? Yes. I updated the notation throughout the document. > > > BTW: Why do we need multi-structures, if a combination has always > exactly one RDF graph? Multi-structures are for the interpretation of RIF documents, not RDF graphs, and RIF documents can import other RIF document.s. > > > * > Conditions 4,6,7,8 in the definition in Section 3.2.1.3 > enforce some "parts of" D-entailment, i.e. somewhat "D minus RDFS", right? > > E.g. let S1= {{ :s :p "foo" }}, S2= {{ :s :p "foo"^^xs:string }} > and R be an emtpy ruleset. That mean that > > <R,S1> |=_simple <R,S2> > > Likewise, given S3= {{ :s :p "blabla"^^xs:integer }} > would <S3,R> |=_simple <S,R> , where S is an arbitrary graph, i.e. > is any combination with a graph containing an ill-typed literal inconsistent? > > This means that simple entailment in combination with an empty ruleset > is not the same as simple entailment in RDF... I think that should be > pointed out explicitly. It would be also worthwhile to add this example, > i.e. I suggest to add (at the end of Section 3.2.3): > > "Note that simple entailment in combination with an empty ruleset > is not the same as simple entailment in RDF, since certain entailments > regarding datatypes are enforced by the RIF-BLD semantics in > combinations. For instance, given two graphs > > G1= { :s :p "foo" .} and > G2= { :s :p "foo"^^xs:string } > > as well as an empty RIF document R. > > G1 |=/=_simpleRDF G2 > > following [http://link-to-rdf-mt-simple-entailment RDF simple entailment] , but > > <R,{G1}> |=_simple <R,{G2}> > " There is already an example to this effect in the introduction to section 3. > > Section 4: > ========== > > > * Section 4.1.1 > "Given a set of OWL 2 DL ontologies O, a variable ?x in a RIF rule Q H > :- B is DL-safe if it occurs in an atomic formula in B that is not of > the form s[P -> o] or s[rdf:type -> A], where P or A occurs in one of > the ontologies in O." > > That doesn't seem to be sufficient, take: > > ?X [rdf:type -> d ] :- Or ( ?X [rdf:type -> c ] p(?X) ) > > this is DL-safe according to the definition above but can be expanded > to two rule one of which wouldn't be DL-safe. > > Rather, we need to adopt a safeness notion similar to Core. You are right. The definition is not sufficient. For now I just defined it for disjunction-free rules. I hope I will be able to include a proper safeness condition later on. You can also have a go at it, if you feel like it. > * Section 4.2.1 > > There is one peculiar thing which I am wondering about: > since we talk about generalized RDF graphs in combinations > and in the definition of entailment, does that mean that > generalized RDF graphs could be entailed by non-generalized ones? > > particularly: > > G1 = > :s :p :o > > G2= > :o [] :p. > > Would: > <R,{G1}> |= <R,{G2}> > ? Yes > > * Section 4.2.2.1 > > > * > Definition (dl-semantic multi-structure): > "I<sub>1C</sub>, ..., I<sub>1C</sub>" > > looks weird, better use 1...n as superscripts as in > http://www.w3.org/2005/rules/wiki/BLD#def-bld-semantic-multistruct > > Again, shouldn't we use \hat{I} rather than I for > multi-structures as in BLD to be consistent? > > * > same definition: > Bullet 1 ends with "and ; " > That looks incomplete, is there anything missing? > > * > "I(φ), for any other formula or symbol φ, and the truth valuation > function TValI are defined as in BLD semantic structures. " > > I am, honestly, getting confused with the definitions of > multi-structures in BLD vs. SWC. > > dl-multistructures consist of {I_1, ..., I_n} > whereas BLD multistructures are {J,I; I_i1, I_i2, ...} > so, I am unsure what "defined as in BLD semantic structures." > means to say. > > (BTW: I sent an amendment to my BLD review per mail > in this regard as well) I updated the definition in SWC to reflect the changes in the definition in BLD. Please have a look. > > * Definition common-RIF-OWL DL-interpretation: > > "(IR union LV) is D<sub>ind<sub>;" > > looks visually a bit strange in my browser, since the ";" appears like a prime on "ind" > i.e. like " ind' " in the subscript and a strange dot on top... > Suggest to add a space: > > "(IR union LV) is D<sub>ind<sub> ;" > > * Definition of model: > > "(I, I) is an OWL DL-model of a DL-condition formula &phi if TVal_I(φ)=t." > > See above, since dl-multi-structures don't talk about J, which seems > to be necessary to interpret non-document formulas, according to the > BLD definitions, I am a bit confused here how TVal_I(φ) is meant > to be defined. I now use TVal_\hat{I}(φ). > > Section 5 > ========= > > * > General question: > What happens if a RIF documents imports ontologies, as well as other > RIF documents that respectively import ontologies? > Is that covered? Where/how? > That is, I am not sure whether/how this "recursive case" is covered in > Section 5.2. This is covered in the first paragraph of section 5.2: "are all the two-ary import statements in R and the documents *imported into* R" > > Section 6 > ========= > > * "Each RIF processor has sets T of supported datatypes and symbol > spaces" > -> > "Each RIF processor has a set T of supported datatypes and symbol > spaces" > > - that sentence is confusing is T the set of datatypes? the set of > sumbol spaces? > - mentioned before: I'd personally prefer to refer to sets of datatypes > uniformly by DTS, instead of T. (There might be a reason for the > distinction, I don't understand it, also made this remark to BLD.) It is a set of datatypes and symbol spaces, as in BLD. > > * > "Formally, for any pair (φ, ψ), where &phi is a BLDT,E-P > combination [...]" > > I think you want to write here: > > "Formally μ is a semantics preserving mapping *to* the language of L > if for any pair (φ, ψ), where &phi is a BLDT,E-P > combination [...]" > > * > "Formally, for any pair (φ, ψ) of formulas in L [...]" > > I am not sure what you want to say here, maybe: > > ""Formally ν is a semantics preserving mapping *from* the language of L > if for any pair (φ, ψ), where &phi is a BLDT,E-P > combination [...]" I prefer not to diverge too much from the conformance text in BLD and Core.Received on Monday, 1 June 2009 09:22:33 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:56 UTC
*