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

Date: Wed, 03 Jun 2009 08:54:54 +0100

Message-ID: <4A262C4E.1050808@deri.org>

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

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

Date: Wed, 03 Jun 2009 08:54:54 +0100

Message-ID: <4A262C4E.1050808@deri.org>

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

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

find my comments inline below. This completes ACION-830 http://www.w3.org/2005/rules/wg/track/actions/830 Overall, I am fine with most of the changes made wrt. Urgent open points: - DL-safeness definition. - Semantic multistructures and dl-multi-structures still look inconsistent. more comments below. Jos de Bruijn wrote: > 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 RDFgraphs" >> >> 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. I am not sure whether I understand this reply, but what I asked was why not several RIF documents can be involved, but ... >> 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. ... this might answer my question from above as well then. >> * >> 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. Then at least a pointer would be worthwhile here, so a short version "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, cf. also Example [pointer-to-example] before." >> 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. Didn't manage to tackle it either, and will likely not be able this week, sorry. >> * 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 Ok. >> * 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. - semantic multistructures and dl-multi0-structures still look inconsistent: section 4.2.2.1 " Formally, a dl-semantic multi-structure Î is a set of dl-semantic structures {J,I, Ii1, Ii2, ...}, where " misses th ";" used in BLD... shouldn't this be: "Formally, a dl-semantic multi-structure Î is a set of dl-semantic structures {J,I; Ii1, Ii2, ...}, where " ? - same here: "Given a dl-semantic multi-structure Î={I1, I2, ...}, " should be: "Given a dl-semantic multi-structure Î={{J,I; Ii1, Ii2, ...}, " >> * 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 likea 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}(φ). ok. > >> 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" ok. >> 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. ok now (after also Michael clarified this for 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. ok, if nobody else complains. Axel -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/Received on Wednesday, 3 June 2009 07:55:37 UTC

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