- From: Jos de Bruijn <debruijn@inf.unibz.it>
- Date: Fri, 10 Apr 2009 18:18:59 +0200
- 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 UTC