[DTB] Action 669 completed

In completion of Action 669
  http://www.w3.org/2005/rules/wg/track/actions/669
I addressed Jos' mail as explained below.

Moreover, I did some more editorial changes in DTB:
These were mainly improving informal descriptions of Mappings for 
certain functions and predicates, and marking those which remain 
informal as such, e.g. see
http://www.w3.org/2005/rules/wiki/DTB#Functions_on_Strings

- for the first function the mapping is explained in detail, for the 
following, the informal explanation is marked as
"Mapping (informal):"

I hope that is acceptable.

Axel

======================================================================


Jos de Bruijn wrote:
> a few comments on [1]:
> 
> - (I asked this question before but did not get an answer) why "intended
> domain"? shouldn't this be just "domain"?

We describe all functions and predicates by
- the name of the built-in.
- the external schema of the built-in.
-  For a built-in function, how it maps its arguments into a result.
-  For a built-in predicate, its truth value when the arguments are 
substituted with values in the domain.
- and finally: intended domains for the arguments

cf. 
http://www.w3.org/2005/rules/wiki/DTB#List_of_RIF_Built-in_Predicates_and_Functions

Do you suggest  to change this in general or only for 
Predicates_on_rdf:text?!?

> - I don't understand the purpose of the second editor's note in section
> 3.3.12.  If the description of the relationship with some SPARQL
> function is desirable, this should be in the main text, not in an
> editor's note.  Such a note should probably point out the difference
> with the SPARQL function.  There is no requirement on BLD that it should
> "emulate" SPARQL functions.

I am fine with removing this Editor's note, if a majority of the group
thinks that emulation of the SPARQL datatype FILTER predicates is not
required for RIF (or at least for RIF BLD). It was mostly to point to 
the fact that it is not possible with the current built-ins.

Note that I added aother editor's note for the hasNotDatatype

> - Analogous to the comparison predicates for functions, the comparison
> predicates for text should also be marked as "under discussion"

done (copied the respective editor's not for the comparison predicates 
for strings).

> - in the specification of these comparison predicates, pred:text-compare
> is not defined and pred:compare is not defined on values of text

fixed, func:compare ad func:text-compare were meant.

Thanks!

Axel


> [1]
> http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20081125/#Predicates_on_rdf:text


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/

Received on Thursday, 4 December 2008 05:01:20 UTC