Re: [DTB] Action 669 completed

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

Right, domain seems much more natural.  At least I understand what it means.

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

Sounds good.

Best, Jos

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

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