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

AW: DTB reviews and todos

From: Adrian Paschke <adrian.paschke@gmx.de>
Date: Tue, 19 May 2009 13:10:26 +0200
To: "'Axel Polleres'" <axel.polleres@deri.org>, "'Public-Rif-Wg \(E-mail\)'" <public-rif-wg@w3.org>
Message-ID: <019501c9d872$69dc5ad0$3d951070$@paschke@gmx.de>
Thanks Axel. 

I quickly checked the implementations of the editors note which we discussed in the last telecon and everything is fine. 

The schema for func:except seems to be wrong - you probably meant ?list1 \ ?list2

Further comments inline in your reply below.


-----Ursprüngliche Nachricht-----
Von: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] Im Auftrag von Axel Polleres
Gesendet: Montag, 18. Mai 2009 21:21
An: Public-Rif-Wg (E-mail)
Betreff: DTB reviews and todos

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?

Adrian: Yes - it keeps the "door" open for Core and PRD

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

Adrian: Yes, reading it twice you’re a right since it explicitly refers to the type.

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

Adrian: Ok

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

Adrian: right, time is running - ok

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
since we also use "primitive" for what are actually "ordinary" datatypes 
following XSD. I suggest we just speak about datatypes.

Adrian: what about "simple 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

Adrian: agree

  if we agree on that, then it also should be adopted in DTB.


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, 
email: axel.polleres@deri.org  url: http://www.polleres.net/
Received on Tuesday, 19 May 2009 11:11:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:56 UTC