W3C home > Mailing lists > Public > public-rif-wg@w3.org > June 2008

Re: [SWC] comments/review SWC - part2

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Mon, 30 Jun 2008 15:44:53 +0200
Message-ID: <4868E355.9050500@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 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:49 GMT