W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2009

Re: [DTB] What is a dialect?

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Fri, 10 Apr 2009 18:18:59 +0200
Message-ID: <49DF7173.5070404@inf.unibz.it>
To: Axel Polleres <axel.polleres@deri.org>
CC: RIF <public-rif-wg@w3.org>


Axel Polleres wrote:
> Jos de Bruijn wrote:
>> The places where the use of the word "supported" is really problematic
>> is in the definitions of "literalNotIdentical" and
>> "isLiteral(Not)OfType".
>> But I expect that these definitions will be awkward, even if "supported"
>> is defined, because they seem to change depending on the dialect at
>> hand. 
> 
> yes.
> 
>> This would violate our requirements on extensibility.
> 
> you mean, because entailments under this function would depend on the
> supported datatypes, yes? Can you point me to the concrete text of the
> requirement?

Resolution from F2F8:
RESOLVED: no invisible extensions (official or user extensions)

http://www.w3.org/2005/rules/wiki/Resolutions

> 
>> The problem is easily solved for isLiteral(Not)OfType, once we define
>> how types are represented (the second argument in the domain is
>> restricted to the set of data types, i.e., all datatypes that have
>> existed, currently exist, and will exist in the world), and it becomes a
>> nonissue if we adopt my proposal [1] and revert back to individual guard
>> predicates.
> 
> Uff. Please not! Sigh. ;-)

What do you propose then? I think we should try and make some progress
towards finalizing DTB.

> 
> 
>> literalNotIdentical is trickier. Basically, the problem is that BLD does
>> not make a distinction between the datatype part of the domain and the
>> rest. So, the domain of a given interpretation can contain some values
>> from the value space of some datatype that is not in DTS. This situation
>> can be remedied by adding to the definition of semantic structures the
>> assumption that the domain does not contain any values of the value
>> space of any datatype that is not in DTS.

Does your silence mean you are in favor of this proposed change?


Jos

>> In that case, one can simply define:
>> Itruth  ╬┐Iexternal( ?arg1  ?arg2; pred:literalNotIdentical( ?arg1 ?arg2
>> ) )(s1 s2) = t if and only if s1 and s2 are in the value spaces of some
>> datatypes and s1 neq s2.
>> (I did not understand what you mean with "point in a space")
> 
> hmmm, that text isn't from me...
> "Identity for typed literals is defined as being the same point in the
> value space for that type."
> Harold? Micheal?
> 
>>
>>
>> Best, Jos
>>
>> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2009Apr/0030.html
>>
>> Axel Polleres wrote:
>>> Jos de Bruijn wrote:
>>>> What is a dialect? And what does it mean for a dialect to support a
>>>> datatype?
>>>>
>>>> This is not defined in DTB, but it is referred to very often. 
>>> Yes, and I firmly believe that a definition of what is a dialect does
>>> not belong into DTB
>>>
>>> It is somewhat defined in FLD (but not spelled out as definition of
>>> "what is a dialect") in the following sense:
>>>
>>> FLD, Section 3.3:
>>> "Semantic structures are always defined with respect to a particular set
>>> of datatypes, denoted by DTS. In a concrete dialect, DTS always includes
>>> the datatypes supported by that dialect. All RIF dialects must support
>>> the primitive datatypes that are listed in Section Datatypes of
>>> [RIF-DTB]."
>>>
>>> That is a datatype is supported by a (logic) dialect, if it is a member
>>> of DTS in the semantic structures for that dialect.
>>>
>>>> In
>>>> particular, what happens if I use a dialect (e.g., BLD), but use more
>>>> datatypes than are strictly required to be supported by
>>>> implementations?
>>>> In addition, it is nowhere specified which datatypes are "supported" by
>>>> Core or BLD.
>>> The semantics of BLD is defined in terms of DTS, but indeed the BLD
>>> document doesn't fix DTS to only those mentioned in DTB, see BLD,
>>> Section 3.2, it is only said that:
>>>
>>> "The effect of datatypes. The set DTS must include the datatypes
>>> described in Section Primitive Datatypes of [RIF-DTB]. "
>>>
>>>
>>> In what is quoted above from FLD and BLD, it is implicit that ALL
>>> dialects must support those DTs in DTB. but it might not be said that
>>> they do not support more. Still, DTB is not the place to define this, is
>>> it?
>>>
>>> Apart from supported datatypes, FLD specifies, and DTB relies on this
>>> (copying the definitions in an appendix, which, re-thinking it, is not
>>> such a brilliant idea) that a dialect defines a Coherent set of external
>>> schemas, DTB defines exactly such a set of coherent schemata.
>>>
>>>
>>> We probably should spell this out in DTB or FLD:
>>>
>>> A RIF dialect needs to define:
>>>  - a set of supported symbol spaces
>>>  - a subset of symbol spaces with a special semantics which are the
>>> supported primitive datatypes
>>>  - a coherent set of external schemata, defining external functions and
>>> predicates.
>>>
>>> Still, even this doesn't define what a dialect IS, does it?
>>> And, does this only apply to logic dialects, does it also apply to PRD?
>>> etc. I have not answer at this point to this and would appreciate
>>> opinions how to address this in DTB.
>>>
>>>
>>> Axel
>>>
>>>
>>
> 
> 

-- 
+43 1 58801 18470        debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
Many would be cowards if they had courage
enough.
  - Thomas Fuller
Received on Friday, 10 April 2009 16:19:49 GMT

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