W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: [RIF] DTB comments

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 11 Jul 2008 19:26:42 +0100
Message-ID: <4877A5E2.5090904@deri.org>
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>'''&rarr; 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:52 GMT