- From: Jos de Bruijn <debruijn@inf.unibz.it>
- Date: Mon, 30 Jun 2008 17:45:49 +0200
- To: Axel Polleres <axel.polleres@deri.org>
- CC: RIF WG <public-rif-wg@w3.org>
>>> BTW, section 2 seems to duplicate some od >>> this stuff anyway. > > >> This text in the overview is about notational conventions used in the >> document. Section 2 is just some explanation of the differences >> between the RDF/OWL syntax and the RIF syntax. Where is the >> duplication exactly? > > I suggest to add a fifth column the table in Section 2 then which shows > the corresponding RIF shortcuts in RIF's presentation syntax, to > illustrate that RIF allows shortcuts very similar looking to the RDF > symbols. There is already such explanation below the table. If this were included in the table, I think this would disrupt the flow of the presentation: I first want to present the correspondence, and then the shortcut syntax. >>> >>> *) 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, >> >> Indeed, they are simply the same. That they have a different syntax >> in RDF is simply a bug (or a feature, depending on how you look at it). >> >>> isn't that a problem for simple RDF >>> entailment? >> >> If you want to support RIF you have to support data types. So if you >> want to combine your RDF data with RIF rules you have to support data >> types. What's the problem? > > For instance, that with a RIF-implementation that implements the > embedding, you cannot check simple RDF entailment? I think the subtle right > difference with plain literals and string typed literals probably > doesn't make a difference normally, but at least, a clarifying remark > pointing this out would be in order, I think! I extended the example in section 3.2.1.2 to also illustrate the difference for the case of strings. I thought about the "clarifying remark" somewhere, but could not think of an appropriate place or appropriate phrase. I do not think this kind of thing belongs in the introductory text; we should not bother the reader too much with such corner cases. If you can think of an appropriate place and location for such a pointer, I would be glad to hear it. >>> *) "there is a corresponcence between RDF triples of the form s p o >>> and RIF frame formulas of the form s[p->o]" -> "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->o]" >> >> This seems to excludes the use of blank nodes and of variables. I >> don't think we want to do that. > > So, how does an RDF triple with blank nodes have a correspondence? > I mean: the correspondence with bnodes is not obvious and defined in > this document (sometimes you replace bnodes by variables sometimes by > sk... so s p o does NOT correspond to s[p->o] for triples with bnodes) > whereas for ground triples it is. Your latter remark about skolemization has no bearing on the main text of the document. Concerning your suggestion for talking about ground RDF triples: as I said in response to some other comment later on, I do not want to go into too much technical detail in this kind of explanatory text, so I'd rather be a bit vague here. In any case, there is an example immediately following the paragraph you mentioned that has variables in frames corresponding to triples. >>> *) "The syntax of the names in these sets [...]" -> "an abstract >>> syntax for the names in these sets [...]" >> >> Isn't there just one abstract syntax? > > There are more than one syntaxes, e.g. the RDF/XML syntax. there is ONE abstract syntax, defined in the RDF-Concepts document. RDF/XML is a concrete syntax. >>> *) "conforming datatype map" ... conforming to what? maybe better use >>> something like "well-defined datatype map" >> >> "Conforming" may not be the best term, but I could not think of >> anything better. > > It is weird. Something that "conforms" conforms to *something*, so what > is this something here? The set of data types you consider for the RIF document. >>> Section 3.2.2: ========= >>> >>> *) You use "a" = "b" as an inconsistency... >> >> I'm not "using" this statement. There is merely an example putting >> something out. > > well, that's nitpicking... you use it for inconsistency, yes? > >>> 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? >> >> Again, I don't see what the problem is. > > the problem is: by > > "a"^^xsd:string = "b"^^xsd:string > > You imply that this is interpreted as an inconsistency. > In simple RDF such an equality is not an inconsistency. > Anyway, If you add the clarifying remark I talked about before, you can > simply reference it here again and just point out that the reader shall > be aware of this treatment in RIF. Just wanted a pointer, because I > think it is not obvious. There is a discussion here of why there is an inconsistency. In addition, I extended the example just above the section to include the example of plain literals versus strings. is that good enough for you? > >>> 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? >> >> Not necessarily. It may also be the location on the local file >> system, for example. >> You may even print a book consisting of an RDF graph, in which case >> you would could the ISBN-IRI :-) >> >>> or named graphs a la Carrol? >> >> I don't know what those are. Is there a standard about them? > > Here some maybe useful paragraph from the SPARQL spec on that for > explainin the maening of the FROM NAMED clause, maybe we can reuse this > analogously: > > "The FROM NAMED syntax suggests that the IRI identifies the > corresponding graph, but the relationship between an IRI and a graph in > an RDF dataset is indirect. The IRI identifies a resource, and the > resource is represented by a graph (or, more precisely: by a document > that serializes a graph). For further details see [WEBARCH]." > > Would need to check in which sense this is clarified in WEBARCH > > [WEBARCH] > Architecture of the World Wide Web, Volume One, I. Jacobs, N. Walsh, > Editors, W3C Recommendation, 15 December 2004, > http://www.w3.org/TR/2004/REC-webarch-20041215/ . Latest version is > available at http://www.w3.org/TR/webarch/ . > >>> maybe needs clarification >> >> I thought to use of IRIs to denote locations, especially locations on >> the Web, is quite obvious to a Web audience. > > If other specs think it is necessary to clarify this with a remark like > the above, we are maybe also better off to follow this practice. What we do here has nothing to do with named graphs. with named graphs, the IRI is an identifier (not necessarily location) of the graph. since this use is nonstandard on the Web, this needed clarification SPARQL. When talking about locations on the Web, I cannot see how there can be any confusion. >>> - 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. >> >> There is a mention of profile in the first paragraph. If anything >> should be further explained, it should be done there. Do you think >> any change is necessary? > > yes: add a forward reference to the predifined list of profiles in this > document in section 5.1 here. I don't really see the point. Especially since section 5 first explains what profiles are, and then defines a number of profiles. I don't think it's a good idea to jump to the definition of the profiles before explaining what they are. > >>> >>> *) "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. >> >> I added the text "Profiles are assumed to be ordered.". Do you think >> this is sufficient? > > Profiles are assumed to be ordered (see ... below). The added text clarifies that there is in order. I don't see the point of forward references, which will only help to confuse the reader, rather than clarifying anything. > >>> *) to the best of his ability - > to the best of its ability >> >> I'm not so sure about this; "its" seems rather impersonal. >> you have some native speakers around in your office in Galway. >> Address them what they think? > > "his" is not gender neutral, I suggest 'its' or 'her/his', I don;t need > a native speaker for making this suggestion which is purely driven by > concerns about political correctness. ;-) I don't believe that calling a person "it" is very politically correct. I personally am not a big fan of polluting the language with political correctness, but to make you happy I wrote "his or her". > >>> *) 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 [...]" >> >> I do not think others should specify generic profiles. > > Fine, it is just not clear from your current wording. I hope it's better now. >>> Section 7.1.1 ======== >>> >>> *) in the last row of the table: "Local constant s^^u' that is not >>> used in C" What is u'? >> >> s^^u' is obtained from "s"^^u. > > How? That is weird. > > You write now: > "Local constant s^^u' obtained from "s"^^u that is not used in C" > > this is still not understandable. I would make an alternative > suggestion, it I understood it! "Local constant <tt>s-u'</tt> that is not used in C and is obtained from <tt>"s"^^u</tt>" Is this better? The idea is that a new constant is generated based on "s"^^u >>> Section 7.1.2 ======== >>> >>> *) "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." >> >> why is it not full Skolemization? > > becaus skolemization introduces skolem-*functions* (not necessarily only > constants) There are no universal quantifiers before the existential quantifiers, so no functions need to be introduced. >>> *) In the last row of the translation table: It seems to me that >>> variable names and bnodes need to be standarized apart as a >> >> What does "standarized apart" mean? > > that blank nodes labels are disambiguated beforehand: This is only the necessary if you do a merge. the graphs are not submerged here; the embedding of each graph gets its own existential quantifier. >>> Section 7.1.3 ======== >>> >> >>> I find the use of the '$' symbol a bit confusing. >>> Couldn't you use I' instead of I$? >> >> I could not get the "'" to work with the wiki formatting. > > did you try <nowiki>'</nowiki> ? It worked, thanks. I replaced all the I$ with I'. > >>> *) By the way: I find the ambiguous use of the letter 'C' for C and >>> I_C possibly confusing. >> >> C is consistently used for combinations, so there will probably not be >> that much confusion. >> Do you have a better suggestion? > > S = <G,R> > > insead of > > C = <S,R> > > maybe? > > because then G is a set of *g*raphs, R is a *r*uleset and we use S for > the combination (I wondered about S for the graph set anyway...) S is commonly used for graphs (e.g., RDF-semantics), that is why I'm using it. >>> >>> Section 7.1.4 ======== >>> >> >>> *) Can't we use pred:isXMLLiteral instead of ex:illxml? If not, >>> shouldn't we define ex:illxml as a predicate in DTB? >> >> As discussed over the phone, the answer is no in both cases. > > I think I would like to have the pred for illxml in DTB... since people > who want to *implement* rif-rfd, need to implement it anyway... or no? No, the predicate does not need to be implemented. It is a very simple axiomatization, depending on the vocabulary of the RDF graph. There is, therefore, no way of defining this predicate without the context of an RDF graph, because ill-typed XML literals cannot be written in RIF. 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 15:44:52 UTC