[SWC] comments/review SWC

Here my review of the 20080610 version of RIF-SWC (that's when I printed 
the document). I saw some changes have been made in between, but I will 
discuss this over with Jos.

best,
Axel


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.
SWC review.


* )  Editors -> Editor (unless you want to add somebody)

Section 1: Overview of RDF and OWL compatibility:
--------------------------------------

*) interoperates with RDF/OWL -> interoperates with RDF, RDFS and OWL.

*) 
"RIF does not provide a format for exchanging RDF graphs, since this 
would be a duplication. Instead, it is assumed that RDF graphs are exchanged using RDF/XML, or any other [...]"
->
"RIF does not provide a format for exchanging RDF graphs; it is assumed that RDF graphs are exchanged using RDF/XML, or any other [...]"

*) "A typical scenario for the use of RIF with RDF/OWL is the exchange of rules that either use RDF data or an RDFS or OWL ontology"
->
"A typical scenario for the use of RIF with RDF/OWL is the exchange of rules that use RDF data possibly along with some  RDFS or OWL ontologies"

*) "The notation of certain symbols particularly IRI's and plain literals is slighlty different from the noation in RDF/OWL. This diference is illustrated in Section [...]."
-->
"The notation of certain symbols particularly IRI's and plain literals is slighlty different from the noation in RDF/OWL. These differences is illustrated in Section [...]."

Do we need this at all? do we need section 2 at all? the latest PS reconciles most of the differences, and section 2 has some flaws anyway, see later comments below.

*) "The Appendix [...] describes how reasoning with combinations of RIF rules with RDF and a sub set of OWL DL can be reduced to reasoning with RIF documents."

If this is a particular fragment of OWL 2 which we can *name*, then this should be mentioned, or another Editor's note should be added.

*) "If the interchange partner B does not have an RDF/OWL aware rule system,but B can process RIF rules[...]"
-->
"If the interchange partner B does not have an RDF/OWL aware rule system,but B can process RIF BLD rules[...]"

*) "All RIF statements are written using the RIF presentation syntax (RIF-BLD). Where possible, this document uses the shortcut syntax for IRIs and strings as defined in (RIF-DTB)."
It was descided that the shortcut notation will be copied to BLD, so probably no need to cross-reference DTB here. BTW, section 2 seems to duplicate some od this stuff anyway.

*) "[...] compact IRIs prefix:localname or typed literals "literal"^^datatype-IRI."
"[...] compact IRIs prefix:localname or typed literals "literal"^^<datatype-IRI>."

Section 2 : Symbols in RIF vs RDF/OWL (Informative)
---------------------------------------

*) "Unicode sequences with symbol space IRIs (DTB)."
-->
 "Unicode sequences  with IRIs denoting their symbol spaces (DTB)."

*) possible problem: In simple RDF there is not entailment for plain literals to 
literals of type xsd:string, but in your treatment you seem to treat both 
synonymously, isn't that a problem for simple RDF entailment? 

*) "Strings, i.e. constants of the form "absolute-IRI"^^xs:string may be written as "absolute-IRI"."
 - I find "absulute-IRI confusing here. why not "<i>mystring</i>"^^xs:string 
 - I used xsd:  as the prefix throughout DTB, I suggest to stick with this and not use xs:

*) I find several things confusing in Table 1. All this should be clear from the explanation of shortcuts in DTB/BLD, no need to duplicate here.  I find this table more confusing than enlighning. E.g.
-  "IRI" is used instead of "constant in the <tt>rif:iri</tt> symbol space
-  "String" is used instead of "constant in the <tt>xs:string</tt> symbol space
- "Symbol in  symbol space" looks strange.
- as mentioned above, I see a possible problem in simple RDF, when mapping plain literals to xsd:string typed literals. I think we can stil do it, but we need to mention then that our entailment is strictly speaking doing more than simple RDF entailment.

Section 3: RDF Compatibility
---------------------


*) "conclusions that may be drawn from the RIF rules are reflected in the RDF graphs"
-> "conclusions that may be drawn from RIF rules are reflected in the RDF graphs"

*) "there is  a corresponcence between RDF triples of the form s p o and RIF frame formulas of the form s[p->]"
->
"there is  a corresponcence between ground (i.e., blank node free) RDF triples of the form s p o and RIF frame formulas of the form s[p->]"

*) in the example: why use john, jack and mary and not the good old alice bob and charles everybody is familiar with? ;-)

*) I find the "nameBearer" example a bit too artificial ... personal taste... what about "namedObject" instead?


Section 3.1.1
----------
*) in the first bullet point there is a font problem

*) "The syntax of the names in these sets [...]"
->
"an abstract syntax for the names in these sets [...]"

*) My only worry about "generalized RDF graphs is: Does this imply that RIF compliant implementations need to support generalized graphs? As mentioned in earlier discussions I think there is reasons NOT to assume the generalization for bnodes in pred positions in future versions of RDF.

Section 3.1.2
----------

*) You miss: double, dateTimeDuration, monthYearDuration, I suggest just to link to DTB or BLD (assuming DTB is only the overall catalogue but not the definition of BLD supported data types) here.

*) I consistently changed "datatype" to "data type" in DTB, we should b e consistent over all documents.

*) "conforming datatype map" ... conforming to what? maybe better use something like
 "well-defined datatype map"

*) "The notion of well-typed literal loosely correspond with the notion of legal symbol in RIF"
->
"The notion of well-typed literal loosely corresponds to the notion of legal symbol in RIF"
 - is there a link reference here to "legal symbol"? (can't see in my pdf print)
 - I don't like "loosely coresponds", this doesn't say anything.


Section 3.2
=======

*) Delete the first sentence "The semantics of RIF documents and RDF graphs are defined in terms of model theories" ... doesn't add anything. 

*) "Combined entailment extends both entailment in RIF and entailment in RDF"
Does it? What about graphs with bnodes... well aehm, seems to work, yes. probalby this comment is void, just to re-check whether the precise formulation of this sentence holds.

*) "which impose additional restrictions on the RDF vocabulary"
-> "which impose additional restrictions on the interpretation of the RDF vocabulary"
likewise for RDFS

*) I do not understand your rationale on capitalizing or non-capitalizing rdf and rdfs.
In my opinion, you should use RDF and RDFS in capital letter anywhere. rdf/rdfs looks 
awkward.

Section 3.2.1
========

*) "correspondence between RDF triples of the form s p o and RIF frames ... (cf. Table 1)"
"correspondence between ground RDF triples of the form s p o and RIF frames ."
- Table 1 doesn't vocer bnodes!


*) possible problem/remark: 
OWL/RDF data or knowledge bases by no means restrict the usage of RIF reserved identifiers or built-ins  as identifiers for arbitrary resources in RDF triples or as OWL classes etc. Is this a possible problem which we should make a remark over? e.g. that we ignore triples using the "RIF vocabulary" (to be defined.)



*) "frame is a mapping from Dind to functions of the form SetOfFiniteBags(Dind × Dind) → D,"

I am not sure wether I understand this. E.g. rdf:type, are not finite... so what does this setoffinitebags mean?

*) "considered datatypes" ... I am a bit worried about these pointers to dtb. Actually, you definition of required RIF datatype points to the required *symbol spaces* definition in DTB

Did you add the respective anchor
<span id="def-required-datatypes" class="anchor">
 in the DTB document? this anchor is confusing, since the list defines symbol spaces, not data types.

Section 3.2.1.2:
==========

*) In ther first definition, I miss a bullet point for plain literals, 6. only seems to cover typed literals.


Section 3.2.2:
=========

*) You use  "a" = "b" as an inconsistency... Don' we again have problems in simple entailment, if we treat plain literals synonymously with xsd:strings?
In simple RDF interpretations  "a"^^xsd:string = "b"^^xsd:string wouldn't be an inconsistency, right?


Section 4:
======

I didn't review section 4 yet.

Section 5:
======

*) "Here, ti is an IRI constant of the form <absolute-IRI>, where absolute-IRI is the location of an RDF graph to be imported, and pi is an IRI constant denoting the profile to be used."

- by "location" you mean web-accessible? or named graphs a la Carrol? maybe needs clarification
- it would be worthwhile to forward-reference to the predifined list of profiles in this document in section 5.1 here. Otherwise, I am a bit lost what a profile IRI actuall is.

*) "In case several graphs are imported in a document, and these imports specify different profile, the highest of these profiles is used."

- At this point the reader has no idea that there is actually an order among profiles, so the meaning of "highest" is unclear... again a remark/forward-reference would be worthwhile for clarification.

*) to the best of his ability - > to the best of its ability

*) The sentence: 
"Any profile that is used with RIF must specify an IRI that identifies it and notions of model, satisfiability, and entailment for combinations."
seems to contradict the notion of the "generic" profile, probably you want to weaken or drop this statement. e.g. "Any non-<tt>generic</tt> profile [...]"

*) Final remark:
I have some worries about the following: What if/How can someone define profile orders for new profiles, particularly, how does someone define profiles which are in a "<" relation with existing profiles defined in this document? I.e., what is rthe intended semantics of "<"? does it mean "monotonicity of (ground?) entailments" or something else? I think this should be defined somehow. Otherwise, some third party could define a complete nonsense order of profiles. 

Section 7: Appendix
=============

*) "RIF-RDF combinations can be embedded into RIF Documents in a fairly straightforward way, thereby demonstrating how a RIF-compliant translator without native support for RDF can process RIF-RDF combinations."
-->
"RIF-RDF combinations can be embedded into RIF Documents which enables RIF-compliant translators without native support for RDF to process RIF-RDF combinations." 

*) "The embeddings are defined using the embedding function tr,"
make tr italic.

*) "Besides the namespace prefix is defined in the Overview,"
->
"Besides the namespace prefixes defined in the Overview,"

BTW: maybe you should simply move this to the overview and also introduce the func: and pred: prefixes there.

Section 7.1
=======

*) "The embedding of RIF-RDF combinations is not defined for combinations that include infinite RDF graphs and for combinations that include RDF graphs with RDF URI references that are not absolute IRIs."

Why are relative IRIs a problem? can be resolved anyway, or no? probably, a reference to the respective section on relative/absolute IRIs in BLD is in order.

Section 7.1.1
========

*) I am worried about row 3 in the table... i.e. the translation of plain literals into xsd:string constants, as I think this can be problematic with respect to simple entailment.

*) in the last row of the table:
"Local constant s^^u' that is not used in C"
What is u'? 

*) "tr("s"^^u) = "s^^u'"^^rif:local"
Unfortunately,  "s^^u'" is not possible in the lexical space of rif:local:
From DTB (this was basically discussed at the f2f in galway):
"The lexical space of rif:local is a subspace of the lexical space of xsd:string. Namely, we allow unicode strings which are also valid XML NCNames as defined in [XML-NS]."

Section 7.1.2
========

*) write the function "sk" in italic. 

*) "and variables are Skolemized, i.e., replaced with constant symbols"
->
"and variables are Skolemized, i.e., replaced with "fresh" constant symbols"

This is not full Skolemization, maybe you should write rather "replaced with fresh constants, similar to Skolemization."

This constant-only-Skolemization only works for a RIF representation of an RDF graph, for a real RIF document, you'd 
need full Skolemization, yes?  

BTW: you use different capitalization for "skolemization", "skolemized", etc. throughoutr the document, that should be aligned.


*) In the last row of the translation table: It seems to me that variable names and bnodes need to be standarized apart as a preprocessing step  before in <R,S>, to make this work. That should be added as a remark.

*) in t1, ..., tm, x1, ..., xn, ... can you change the indexes to subscript?



Section 7.1.3
========

*) "Even though the semantics of the RDF vocabulary does not need to be axiomatized for simple entailment, the connection between RIF class
membership and subclass statements and the RDF type and subclass statements needs to be axiomatized."

hmmm, something in this sentence is confusing, not sure what... mayb just cutting it down to:
"The connection between RIF class membership and subclass statements and the RDF type and subclass statements needs to be axiomatized."
would be fine.

*) "by using the embeddings of RDF graphs defined in the previous section."
->
"by using the embeddings of RDF graphs defined above."
(the previous section is section 6...)

*) General comment on the embedding theorems and proofs:

It seems to me that you should rather group.

"A RIF-RDF combination <R,{S1,...,Sn}> is satisfiable iff there is a semantic multi-structure I that is a model of merge({R, Rsimple, trR(S1), ..., trR(Sn)}). "

and

"A RIF-RDF combination C=<R,{S1,...,Sn}> simple-entails a generalized RDF graph T if and only if merge({R, trR(S1), ..., trR(Sn)}) entails trQ(T)."

in one theorem, and proof it by the Lemma:

"C simple-entails an existentially closed RIF-BLD condition formula φ if and only if merge({R, Rsimple, trR(S1), ..., trR(Sn}) entails φ."

That seems more logical than grouping the latter two in a theorem, i.e.: the important (theorem) are the former two, the latter is a lemma from which 
these two follow. As it looks now, the second theorem says two different things at once, which are not logically related. If you group it the other way 
around, you can just proof the last one, and the other two follow logically...

proof: => side:

*) In the proof, why doe we need the paragraph
"Assume now that R' does not entail trQ(T), [...]"
in the end of the => direction at all? It seems that the proof of the => side is complete before, and this paragraph could, especially if you regroup the 
theorem/lemma as suggested just be mentioned as "a consequence of the lemma".

proof: <= side:

*) What is I$, I find the use of the '$' symbol a bit confusing. Couldn't you use I' instead of I$?

*) By the way: I find the ambiguous use of the letter 'C' for C and I_C possibly confusing.

*) Again, the paragraph  "Assume now that C doe not entail ..." seems a bit redundant. Again, regrouping the theorem, and then saying
that this is a consequence of the application of the lemma as mentioned above, would make this shorter.

Section 7.1.4
========

*) "We assume that ex:illxml is not used"
->
"We assume that the constant ex:illxml is not used"

*) Can't we use pred:isXMLLiteral instead of ex:illxml? If not, shouldn't we define ex:illxml as a predicate in DTB?

*) similar considerations for structuring the theorem/lemma/proof apply as for section 7.1.3:

1) Theorem:

"A RIF-RDF combination C=<R,{S1,...,Sn}> rdf-entails a generalized RDF graph T iff merge({RRDF, R, trR(S1), ..., trR(Sn)}) entails trQ(T)"

2) the theorem is an immediateconsequence of the lemma:

"C rdf-entails an existentially closed RIF-BLD condition formula φ iff merge({RRDF, R, trR(S1), ..., trR(Sn)}) entails φ."

3) The lemma has a long proof, but you can drop some paragraphs.

4) The now first theorem is actually a corollary:

"A RIF-RDF combination <R,{S1,...,Sn}> is rdf-satisfiable iff there is a semantic multi-structure I that is a model of merge({R, RRDF, trR(S1), ..., trR(Sn)})."

Section 7.1.5
========

*) similar considerations for structuring the theorem/lemma/proof apply as for section 7.1.3.

Received on Monday, 23 June 2008 12:13:27 UTC