- From: Axel Polleres <axel.polleres@deri.org>
- Date: Fri, 11 Jul 2008 15:46:58 +0100
- To: Stella Mitchell <cleo@us.ibm.com>
- CC: RIF <public-rif-wg@w3.org>
Stella: Thanks a lot, I inded overlooked it before!!!
All: Since not all of these comments are editorial only, how shall I
proceed with implementing them, as the version is frozen now?
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
>
>
--
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.
Received on Friday, 11 July 2008 14:47:55 UTC