- From: Jos de Bruijn <debruijn@inf.unibz.it>
- Date: Mon, 30 Jun 2008 15:44:53 +0200
- To: Axel Polleres <axel.polleres@deri.org>
- CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Axel, Thanks for the comments. Find replies in line, where appropriate. > This part 2 of the review from > http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0126.html > covers Section 4 which wasn't covered in the first review. More > comments on the RIF-OWL embeddings in the Appendix to follow. > > Section 4 ======= > > *) "OWL (OWL-Reference) specifies three increasingly expressive > species, namely Lite, DL, and Full." > > Side remark, probably no rewording necessary, but doesn't OWL Lite > have exactly the same expressive power as OWL DL? Thus, "increasingly > *expressive*" is maybe not ideal wording, but I don't have a better > suggestion. OWL DL is strictly more expressive than OWL Lite, since OWL Lite does not allow expressing nominals. > *) "the interpretation of frame formulas s[p -> o] in the RIF-OWL DL > combinations is slightly different from their interpretation in RIF > BLD and syntactical restrictions are imposed on the use of variables, > function terms, and frame formulas." > > That honestly worries me. Is it wise to do that? What are the > implications? Is this still FLD compatible? That means that RIF-OWL > is not compatible with BLD? If so, in what sense uncompatible? See > also my comments below. This has been extensively discussed in a face-to-face, as well as on the mailing list, sometime ago. I honestly don't feel like repeating this discussion. > Section 4.1 ======= > > * ) "DL-Document" is not so nice... I'd prefer > "RIF-BLD-DL-Document" or "RIF-BLD<sub>DL</sub>-Document" I was trying to stay in line with the terminology used in BLD. BLD does not specify anything like an RIF- BLD -document or an RIF document. that seemed a good idea at the time, and I would prefer sticking with that unless anyone can come up with a convincing argument to diverge . > > Section 4.1.1 ========= > > > *) "and every variable in if that is not DL-safe occurs only in > atomic formulas in if that are of the form s[P -> o] or s[rdf:type -> > A], where P or A, respectively, occurs in one of the ontologies in O. > " -> "and every variable in the if-part that is not DL-safe occurs > only in atomic formulas that are of the form s[P -> o] or s[rdf:type > -> A] such that P or A, respectively, occur in one of the ontologies > in O. > > BTW: Isn't this second part redundant? I mean, every variable in the > if part for which this condidtion does NOT hold, is per definition > DL-safe anyway, or no? So..? You are right. It is redundant and I removed it. > > *) I wonder if equating something with rdf:type in a fact e.g. > > ex:a = rdf:type . (this is perfectly DL-safe as a fact, isn't it?) > > messes up the whole "safety" section? Because now I could add a rule: > > > ?X[ex:a eX:C] :- ?X[ex:a eX:D] > > that would hurt safety, but not syntactically, or no? What I mean to > say: Isn't there an interplay with that definition of safety and > equality in the rules language? If so, that puts the talking about > safety even more at risk, or we need to additionally forbid nasty > equalities in the rules part, at least. There is no such interplay, because with the modified semantics for frame formulas, the c in a[rdf:type-> c] and a[c -> b] is interpreted contextually, and is thus independent from occurrences of c in any other place. > > Section 4.2.2 ========= > > *) Where is "SetOfFiniteFrame'Bags" defined?!? What is the difference > to "SetOfFiniteBags" from BLD and FLD, if your semantics doesn't > specialize FLD even, it seems a bit weird to me. Not sure whether I > understand what's happening here. It should be "SetOfFiniteBags". I corrected it. > > Section 4.2.2.2 ========== > > *) "R is a non-empty set of resources (the domain); O is a non-empty > subset of R, disjoint from LV" > > O comes out of nowhere here, it is not a part of I=< R, EC, ER, L, > S, LV > should it be: "I=< R, O, EC, ER, L, S, LV >" instead??? I rephrased the text a little, so that it seems less awkward . I'm trying to follow the OWL specification in the definitions. > > Definition common-rif-dl-interpretation: ========================== > > *) Condition 2. : "I_truth(I_frame'(I_C(rdf:type))(k,I_C(<c>))) = t > " > > Note here that: (k,I_C(<c>)) is not a "SetOfFiniteFrame'Bags", at > least it doesn't seem to be, since "SetOfFiniteFrame'Bags" is not > defined, so I have a hard time grasping what you want to say. I > suppose though, you want > > (k,I_C(<c>)) to be a shortcut for all finite bags containing > (k,I_C(<c>)) in arbitrary arity >0 ? (k,I_C(<c>)) was intended to be a singleton bag. I was not careful in the notation, but this is fixed now. Then, according to one of the conditions on RIF semantic structures, a pair is in some finite bag iff it is in the singleton comprising that pair: TValI(o[a1->v1 ... ak->vk]) = t if and only if TValI(o[a1->v1]) = ... = TValI(o[ak->vk]) = t. [1] [1] http://www.w3.org/2005/rules/wiki/BLD#Interpretation_of_Non-document_Formulas > > *) The very last example in section 4.2.2.2: "However, the mapping EC > in any abstract OWL interpretation requires every member of ex:A to > be an element of O, and concrete data values may not be members of O. > " > > maybe better: > > "However, the mapping EC in any abstract OWL interpretation requires > every member of ex:A to be an element of O, and the non-empty set ot > concrete data values for Data types in OWL is disjoint from O." > > not sure whether this reformulation really works, but the problem > with yours is that "may not be members" sounds to me like... well > that doesn't imply that there is no interpretation, but only that > there may be interpretations which don't work. This should be made > stronger/clearer. I replaced "may not" with "cannot". I think this removes ambiguity. > > *) "It is currently expected that OWL 2 will not define a semantics > for annotation and ontology properties; therefore, the below > definition cannot be extended to the case of OWL 2. " > > You countered one of my earlier questions about OWL2 with the > argument that this document doesn't talk about OWL2... fine, so why There is *no* technical discussion about OWL 2. > you then keep still several links to OWL2 here? (Also when you talk > about punning earlier), The discussion of OWL 2 anticipates questions readers may have, particularly pointing out places where differences between OWL and OWL 2 impact combinations. > and you also don't mention OWL2 in the > references. That is because there is nothing to refer to (I do not think it appropriate to refer to working drafts). > I suggest to mark all speculative references to OWL2 as > editor's notes/at risk/ There is no technical discussion about OWL 2, so there is nothing "at-risk". The notes about OWL 2 are part of the explanatory text; they have no place in the editor's Notes, which are notes about the document itself. > > *) "Definition. Given a conforming datatype map D, a > common-rif-dl-interpretation (I, I) is a > common-DL-annotation-interpretation if the following condition holds > > 6. ER(p) = set of all pairs (k, l) in O × O such that > Itruth(Iframe'(IC(<p>))( k, l) ) = t (true), for every IRI p in V. > " > > Isn't this better named condition 3'. and *replace* condition 3. from > above definition? You had this comment earlier, and it's really a matter of opinion what one finds more elegant. I am the editor, so I chose the option I find most elegant :-) Best, Jos > > > -- -- Jos de Bruijn debruijn@inf.unibz.it +390471016224 http://www.debruijn.net/ ---------------------------------------------- If knowledge can create problems, it is not through ignorance that we can solve them. - Isaac Asimov
Received on Monday, 30 June 2008 13:43:56 UTC