- From: Axel Polleres <axel.polleres@deri.org>
- Date: Fri, 11 Jul 2008 19:26:42 +0100
- To: Stella Mitchell <cleo@us.ibm.com>
- CC: RIF <public-rif-wg@w3.org>
Stella, again many thanks for your detailed review. Comments inline!
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?
That is commented out now. Since we didn't agree on a shortcut notation
for rif:text, you have to use the long version, i.e.:
"Hello@en"^^rif:text
for the moment.
In the source code of the grammar, there is also commented out:
"
<!-- | STRING LANGTAG <i>'''→ shortcut for'''</i>
"..."^^rif:text -->
since it was not agreed (awaiting resolution of the rif:text issue with
the OWL WG, it is noted with an Edtor's note as well.)
> Sections 4.1 and 4.2:
> add guard and negative guard predicates for xsd:date
done.
> Section 4.3
> add a cast function for xsd:date
done.
> 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 ...
Indeed an ommission, fixed.
I also added an example in the end of that section, which I would like
the others to re-check again on how to use this built-in to convert
URIs to strings.
> Section 4.4.1.4 (func:numeric-divide)
> Mapping bullet:
> Delete the first sentence (looks like a leftover
> copy/paste)
done.
> Section 4.4.2
> add pred:numeric-not-equal
Why? It is not backed up by any XPath/XQuery function. If you think we
need inequality-predicates per datatype, I think this should be raised
as an issue. I do not remember any resolution which had decided to do
such a thing.
> 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)
Why? My rationale was to add most functions related to the supported
datatypes. In general, at this point, I suggest for the addition/removal
of concrete functions to decide on a formal process, unless it is simple
ommissions such as e.g. the isDate above.
So, whoever wants a func/pred to be removed/added should "apply" for it
to the group in a separate email and we decide in separate resolutions. Ok?
> 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
Thanks, that seems to be editorial, we did not want xs:long.
> 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).
Hmmm, I changed/weakened that to
"RIF dialects are expected to include the following symbol spaces.
However, rule sets that are exchanged through RIF can use additional
symbol spaces."
and
"RIF dialects are expected to support the following primitive datatypes.
However, RIF dialects may include additional datatypes."
Is this acceptable? If not, other proposals welcome.
> 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...
Good idea for the next version, I'd rather leave that out for now.
> Typos & wording suggestions:
> ---------------------------------------------
> Section 1
> ----------------
> 1st sentence:
> make "RIF's presenation syntax" a link
To where?
http://www.w3.org/2005/rules/wiki/BLD#Direct_Specification_of_RIF-BLD_Presentation_Syntax
(but this is only BLD)
> 2.1. Constants and Symbol Spaces
> -----------------------------------------------------
> 1st para, last sentence:
> identified by IRI --> identified by <identifier>
>
obsolete
> Definition (Symbol space):
> FLD also has a third bullet saying that two symbol spaces
> cannot share
> the same identifier
Added in the following wording:
"* Different symbol spaces supported by a dialect cannot share the same
identifier."
Theoretically, two people could define the different symbol spaces with
the same IRI... just to be on the safe side.
> 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.
Suggestions? I think it is ok like this.
> bulleted list:
> xsd:decimal bullet:
> corresponds --> correspond
probably obsolete comment?
> 2 duration bullets:
> 2nd bullet:
> xsd:dayTimeDuration --> xsd:yearMonthDuration
probably obsolete comment?
> 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.
reworded, slightly differently.
> 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"
I think this is an obsolete comment.
> 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
hmmm. not sure, I left this. If you insist, pls give me a rationale.
> 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?
not sure what you mean here, may be obsolete by changes in between.
> 2nd para:
> defined in in --> defined in
done.
> For RIF's normative syntax, see XML Serialization Syntax
> for RIF-BLD -->
> For RIF's normative syntax, see XML Serialization Syntax
> for RIF-FLD ?
reworded, now also pointing to FLD.
> 3rd para:
> both the well-formed externally defined terms and their
> syntax -->
> both the syntax and semantics of exernally defined terms
done.
>
> schemas have especially simple form -->
> schemas have an especially simple form
done.
> 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?
I'd rather leave it for this first WD.
> 4 List of Supported Built-in Predicates and Functions
> ----------------------------------------------------------------------------
>
> How about changing the section heading to: "RIF Built-in Predicates
> and Functions"?
>
now: List of 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.
done. reads better, indeed.
> 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
obsolete.
> 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.
obsolete.
> 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
is that wrong or you just prefer the latter? I prefer it as is.
> 4.3 Cast Functions...
> ------------------------------
> for all its supported data types -->
> for all of the data types
obsolete.
> 4.3.3 rdf:XMLLiteral
> ------------------------------
> Mappings bullet:
> Mappings --> Mapping
> givne --> given
done.
>
> 4.3.4 rif:text
> ----------------
> Mapping bullet:
> s --> s1
done.
> 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?
good catch, I added: "which is in the lexical space of the
<tt>rif:iri</tt> symbol space"
> "a"^^xsd:iri --> "a"^^rif:iri
done.
> there are a few <tt> tags in the last paragraph
obsolete.
> 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
now added the example, pls check!
> Schema bullet:
> (?arg1, ?arg1) --> (?arg1, ?arg2)
done.
> Intended domain bullet:
> aregument --> argument
done.
> Mapping bullet:
> (?arg1, ?arg1) --> (?arg1, ?arg2)
done.
> is en --> is in
done.
> 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?
I qualified it.
> 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)
could be refined in a next version, I would prefer to leave it for the
moment, there is an Editor's note that says that some explanations will
need refinement.
> 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?
I qualified it.
> 4.5 Functions and Predicates on Strings
> ----------------------------------------------------------
> 2nd para:
> we equally allow simply to write --> we allow the equivalent forms
ok.
> 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.
This is marked with an editor's note. I think it is not general and
would blur BLD.
> 4.5.1.2 func:concat
> ----------------------------
> (?arg1; func:concat1(1)) --> (?arg1; func:concat1(?arg1))
fixed.
>
> 4.5.1.3 func:string-join
> --------------------------------
> schema bullet
> two of them are named join2
fixed.
> 4.5.2.4
> ---------
> pred:matchess --> pred:matches
obsoltete.
> 6 Appendix
> -----------------
> RIF-BLD --> RIF-DTB
>
not sure what you meant, I changed the second sentence to:
"This section is an edited copy of a section from [[FLD|RIF Framework
for Logic Dialects]]. It is reproduced here for convenience of readers
familiar with the [[BLD|RIF-BLD document]] who might not have studied
RIF-FLD."
hope that's clearer.
All for now. Great stuff!
--
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 18:27:24 UTC