- From: Jos de Bruijn <debruijn@inf.unibz.it>
- Date: Fri, 11 Jul 2008 16:56:13 +0200
- To: Axel Polleres <axel.polleres@deri.org>
- CC: Stella Mitchell <cleo@us.ibm.com>, RIF <public-rif-wg@w3.org>
> All: Since not all of these comments are editorial only, how shall I > proceed with implementing them, as the version is frozen now? I know that certainly BLD should be refrozen (but after we conclude the discussion in the thread [1], and of course after the okay from Michael and Harold), and I think SWC should also be refrozen (this can be done now, unless people have further comments). So, I think you should just go ahead and address the comments. Best, Jos [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0098.html > > I suggest, I implement the editorial ones and summarize the others in a > follow-up mail. > > Axel > > Stella Mitchell wrote: >> >> Hi Axel, >> >> I'm resending these comments (slightly updated) from a few weeks ago, >> because I don't >> know if you saw them. I think the items in the first section are >> simple errors that could >> be corrected for this WD. I didn't check the typos and wording >> suggestions against the >> current document. >> >> Stella >> >> >> Comments: ----------------- >> >> The text of the abstract is missing. >> >> Section 2.1.2 >> EBNF: LANGTAG is not used, rif:text types are not >> covered? >> Sections 4.1 and 4.2: >> add guard and negative guard predicates for xsd:date >> >> Section 4.3 >> add a cast function for xsd:date >> >> Section 4.3.6 >> I think the motivating example in the 1st paragraph is not >> complete: >> this would immediately result in ... >> --> >> and then if a ruleset asserted >> "http://example.org/iriA"^^rif:iri = >> "http://example.org/iriB"^^rif:iri, this would result in >> ... >> >> Section 4.4.1.4 (func:numeric-divide) >> Mapping bullet: >> Delete the first sentence (looks like a leftover >> copy/paste) >> >> Section 4.4.2 >> add pred:numeric-not-equal >> >> Sections 4.6.1 & 4.6.2 >> remove the predicates and functions related to >> xsd:duration type >> (4.6.1.13-4.6.1.18 and 4.6.2.10) >> >> Document: >> To match the list of data types in section 2.2, a number of >> references to >> xs:long throughout the document need to be updated to >> xs:double >> >> The text in sections 2.1.1 and 2.2 says that all RIF >> dialects must >> include all the symbol spaces and data types. (as opposed to >> the catalog idea, where each dialect specifies which subset >> it requires). >> >> General: >> ------------- >> How about renaming the first section to Introduction or >> Overview, (keeping >> the current content) and adding some introductory description >> about how >> this document fits with the others (as described in the >> abstract), intended >> audience, how it should be updated when new dialects are >> defined, and >> general topics such as that rule sets can use additional symbol >> spaces >> that are not included in this document... >> >> >> Typos & wording suggestions: >> --------------------------------------------- >> Section 1 >> ---------------- >> 1st sentence: >> make "RIF's presenation syntax" a link >> >> 2.1. Constants and Symbol Spaces >> ----------------------------------------------------- >> 1st para, last sentence: >> identified by IRI --> identified by <identifier> >> >> Definition (Symbol space): >> FLD also has a third bullet saying that two symbol spaces >> cannot share >> the same identifier >> >> Next para: >> However, to simplify --> <new para> For convenience, >> ("However" doesn't seem like an appropriate link >> between the 2 sentences) >> >> Next para: 2nd sentence: >> Maybe expand on the statement about rulesets being >> able to use >> additional symbol spaces. >> >> bulleted list: >> xsd:decimal bullet: corresponds --> >> correspond >> >> 2 duration bullets: >> 2nd bullet: >> xsd:dayTimeDuration --> xsd:yearMonthDuration >> >> para before EBNF: >> I think it reads better reworded as: >> In order to make rules written in RIF's presentation >> syntax more readable, >> the syntax includes shortcut notations for constants in >> several of the >> symbol spaces. RIF's presentation syntax for constants >> is defined by >> the following EBNF. >> UNICODESTRING: >> escpape --> escape >> >> last para before section 2.2: >> Other than the first sentence, the rest of the text seems >> out of place here - >> or it should have a different lead in, other than "For >> instance" >> 2.2. Data Types >> ----------------------- >> 3rd para: >> DTS always includes the data types supported by that >> dialect --> >> DTS always includes the data types required by that dialect >> >> 3.1 Syntax of Built-ins >> ------------------------------- >> 1st para: >> does BLD need to be called out here, (since this is >> supposed to >> be common to all dialects? >> >> 2nd para: >> defined in in --> defined in >> >> For RIF's normative syntax, see XML Serialization Syntax >> for RIF-BLD --> >> For RIF's normative syntax, see XML Serialization Syntax >> for RIF-FLD ? >> >> 3rd para: >> both the well-formed externally defined terms and their >> syntax --> >> both the syntax and semantics of exernally defined terms >> >> schemas have especially simple form --> >> schemas have an especially simple form >> >> 3.2 Semantics of Built-ins >> ------------------------------------- >> 1st para: >> does BLD need to be called out here, since this is supposed >> to be common to all dialects? >> >> 4 List of Supported Built-in Predicates and Functions >> ---------------------------------------------------------------------------- >> >> How about changing the section heading to: "RIF Built-in >> Predicates and Functions"? >> >> list item 5 (intended domains): >> I think the last 2 sentences of first paragraph read better >> reworded as: >> This means that if one or more of the arguments is not >> in its intended domain, the >> value of */I/*_external (ó)(a_1 ... a_n ) can vary >> from one semantic structure to another. Similarly, */ >> I/*_truth ï */I/*_external (ó)(a_1 ... a_n ) can be *t* in >> some interpretations and *f* in others when an argument >> is not in the intended domain. >> >> 4.1 (same comments apply to section 4.2 ) >> --------------------------------------------------------------- >> 1st para: >> RIF requires guard predicates for all its supported data types --> >> RIF requires guard predicates for all its data types >> >> Also, section 4.2 uses 'has' where this sentence says 'requires' >> and at the end of section 4.2 it says that RIF does *not* >> require guards >> for all data types. >> >> 1st bullet: >> for one of the RIF supported data types --> >> for one of the RIF data types >> >> where applicable without creating ambiguities --> >> where applicable as long as they don't create ambiguities >> >> 4.3 Cast Functions... >> ------------------------------ for all its supported data >> types --> >> for all of the data types >> >> 4.3.3 rdf:XMLLiteral >> ------------------------------ >> Mappings bullet: >> Mappings --> Mapping >> givne --> given >> >> 4.3.4 rif:text >> ---------------- >> Mapping bullet: >> s --> s1 >> 4.3.5 rif:iri >> ---------------- >> "The following equalities hold in every RIF interpretation for >> each unicode string a:" >> --> for each string, or only for those that are in a >> certain format? >> >> "a"^^xsd:iri --> "a"^^rif:iri >> >> there are a few <tt> tags in the last paragraph >> >> 4.3.6 pred:iri-to-string >> -------------------------------- >> 1st para: >> the link to the rif:iri cast function needs to be fixed up >> >> 2nd para: " (see example below)" -- can't find the >> example below >> >> Schema bullet: >> (?arg1, ?arg1) --> (?arg1, ?arg2) >> >> Intended domain bullet: >> aregument --> argument >> >> Mapping bullet: >> (?arg1, ?arg1) --> (?arg1, ?arg2) >> >> is en --> is in >> >> 4.4.1 Numeric Functions >> ----------------------------------- >> which functions does the sentence between sections 4.4.1.1 and >> 4.4.1.2 apply to? >> should it be moved to the beginning, or qualified? >> >> 4.4.1.4 func:numeric-divide >> ---------------------------------------- >> Mapping bullet: >> I'm not sure "backs up the "div" operator" is >> self-explanatory enough for a reader >> of this document? (same comment for next few sections) >> >> 4.4.2 >> ------- >> which predicates does the sentence between sections 4.4.2.1 and >> 4.4.2.2 apply to? >> it should be qualified and possibily moved to the beginning? >> >> 4.5 Functions and Predicates on Strings >> ---------------------------------------------------------- >> 2nd para: >> we equally allow simply to write --> we allow the equivalent >> forms >> >> The comment about not lifting restrictions made in BLD seems >> like >> it would be better placed in the BLD document, since DTB is >> supposed >> to be general to all dialects. >> >> 4.5.1.2 func:concat >> ---------------------------- >> (?arg1; func:concat1(1)) --> (?arg1; func:concat1(?arg1)) >> >> 4.5.1.3 func:string-join >> -------------------------------- >> schema bullet >> two of them are named join2 >> 4.5.2.4 >> --------- >> pred:matchess --> pred:matches >> >> 6 Appendix >> ----------------- >> RIF-BLD --> RIF-DTB >> >> > > -- 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 Friday, 11 July 2008 15:08:02 UTC