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

Re: [DTB] Action 669 completed

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Thu, 04 Dec 2008 10:00:17 +0100
Message-ID: <49379C21.80704@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: RIF WG <public-rif-wg@w3.org>
> 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"?

Let me try to rephrase:
in mathematics, a function has a domain and a co-domain.  A relation has
a domain.
What is an "intended 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.

As I said, this is not an editorial point but a property of the
predicate. Let me quote from my comment:

>> 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.


Best, Jos

> 
> 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
>>
> 
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster


Received on Thursday, 4 December 2008 09:00:23 GMT

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