# Re: [SWC] my review (part I - excl. informative Appendix)

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>
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(&phi;), for any other formula or symbol &phi;, 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(&phi;)=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(&phi;) is meant
> to be defined.

I now use TVal_\hat{I}(&phi;).

>
> 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 (&phi;, &psi;), where &phi is a BLDT,E-P
> combination [...]"
>
> I think you want to write here:
>
> "Formally &mu; is a semantics preserving mapping *to* the language of L
> if for any pair (&phi;, &psi;), where &phi is a BLDT,E-P
> combination [...]"
>
> *
> "Formally, for any pair (&phi;, &psi;) 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 (&phi;, &psi;), 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 GMT

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