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

Re: [DTB] What is a dialect?

From: Axel Polleres <axel.polleres@deri.org>
Date: Fri, 10 Apr 2009 17:43:12 +0100
Message-ID: <49DF7720.4060700@deri.org>
To: Jos de Bruijn <debruijn@inf.unibz.it>
CC: RIF <public-rif-wg@w3.org>
Jos de Bruijn wrote:
> 
> 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

Ok, I digged that up.

"An Invisible Extension defines a dialect which has exactly the same 
syntax as some other dialect but different semantics. This is sometimes 
desirable when the different semantics are related in a practical and 
useful way, such as reflecting the different capabilities of competing 
implementation technologies. Deployment, testing, and the definition of 
conformance for invisible extensions require out-of-band information, 
which may be problematic. For example, there is a subset of OWL-Full 
which has the same syntax as OWL-DL, but which has more entailments (ie 
different semantics). This subset of OWL-Full is an invisible extension 
of OWL-DL; its presence (and thus the different intended semantics) 
cannot be determined by inspection and must be conveyed out-of-band in 
any applications where the semantic difference might matter."

I remember in that context we discussed two possiblt solutions of that:
top-of-document tag to identify the dialect or syntactic elements used 
-- either way is feasible to avoid invisible extensions, whereas you 
seem to limit to the latter.
Note that the former precludes e.g. also to use the same symbol for naf 
in possible well-founded semantics and stable semantics dialects...

Axel

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

would dialect-tags per document work?
going back to guards and dropping isLiteralOFType looks like a step back 
to me.

> I think we should try and make some progress
> towards finalizing DTB.

yes, sure.


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

I am neutral on that, because I haven't thought yet about implications, 
but doesn't sound bad.

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


-- 
Dr. Axel Polleres
Digital Enterprise Research Institute, National University of Ireland, 
Galway
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Friday, 10 April 2009 16:43:55 GMT

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