- From: Axel Polleres <axel.polleres@deri.org>
- Date: Mon, 18 May 2009 20:21:20 +0100
- To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
Apart from Michael's mail [1] and Adrian's preliminary review [2] I didn't get updated reviews yet. They have both been addressed, some maybe need discussion: > Section 2.2. > > “The semantics of external terms in RIF-FLD and RIF-BLD is defined using > two mappings: Iexternal and Itruth ο Iexternal….” > > What about RIF Core and RIF PRD. The condition language of PRD and the newly > introduced external print built-in use this semantics from DTB (FLD) – so > they should be mentioned as well. For the moment, I changed this to: "The semantics of external terms is defined using two mappings: Iexternal and Itruth ο Iexternal…." does that do the trick? > “RIF supports identity for typed literals through the "=" predicate in all > dialects that extend RIF-CORE. Identity for typed literals is defined as > being the same point in the value space for that type.” > > That would disallow future order-sorted typed RIF dialects to be extensions > of RIF Core – literals are equal if they belong to the same sort (type) or > a sub-type. I don't see that this is prevented. The identity notion can be extended for those, but the sentence still holds, doesn't it? I left that unchanged. > 3.6.1.1 func:not > Maybe we should add a sentence about the difference of this not function > built-in and negation as e.g. in PRD to make it explicit – but it is also > fine as it I left it as it is. > Maybe a general “RIF DTB Extensibility” section at the end could be > helpful which describes how future RIF dialects would extend RIF DTB and how > user-defined functions and built-ins can be defined with respect to the > “normative” DTB built-ins. Good idea, but I not if we want to go to LC tomorrow. otherwise I am open to discuss this. Anyways the necessary ingredients are there in DTB. We could mention PRD as an example of a dialect that extends the coheent set of external schemata of DTB. Here two more TODOs which are less clear: * Speaking of "primitive datatypes" should be avoided We call our datatypes "primitive" but this is not in compliance with http://www.w3.org/TR/xmlschema11-2/#dt-primitive since we also use "primitive" for what are actually "ordinary" datatypes following XSD. I suggest we just speak about datatypes. * in my BLD review, I suggested that the Base Directive should refer to *absolute* iri: "where iri is a unicode string in the form of an *absolute* IRI [RFC-3987]." if we agree on that, then it also should be adopted in DTB. Axel 1. http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0135.html 2. http://lists.w3.org/Archives/Public/public-rif-wg/2009May/0101.html -- Dr. Axel Polleres Digital Enterprise Research Institute, National University of Ireland, Galway email: axel.polleres@deri.org url: http://www.polleres.net/
Received on Monday, 18 May 2009 19:22:06 UTC