Re: [DTB] Action 669 completed

So, it seems to me we need two three resolutions, see below... would be 
good if we could vote over these in the next telecon (which I am not yet 
sure whether I can attend due to travelling, but if I see the reolutions 
in the minutes, I can implement them)

1) Ss for the unaddressed comment from 
http://lists.w3.org/Archives/Public/public-rif-wg/2008Jun/0125.html

  I changed that: short names are now defined in the Section on symbol 
spaces: http://www.w3.org/2005/rules/wiki/DTB#Symbol_Spaces
(I found it more natural to include that with the symbol space than with 
the datatype.)

PROPOSED: Every datatype has a short name. the definition of short names 
shall be included in Section 1.2.1 on symbol spaces. guard predicates 
and negative guard predicates shall refer to these short names.

Jos de Bruijn wrote:
>> 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"???

2) Secondly: So, you suggest...

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

... to change this in general and just remove the word "intdended" 
anywhere? Fine for me, but guess we need a resolution or at least 
michael's approval who came up with the "intended domain" initially.

PROPOSED: Change "intended domain" to "domain" throughout DTB.

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

3) I am fine to change that to a note in the text...

PROPOSED: Change the editors note in DTB the differences of 
pred:hasDatatype to sparqls datatype FILTER built-in to a note as follows:

"Note that this example shows pred:hasDatatype behaves differently than 
SPARQL's [http://www.w3.org/TR/rdf-sparql-query/#func-datatype datatype] 
function."

best,
Axel


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


-- 
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 12:53:14 UTC