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

Re: symbol space short names

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Sun, 17 May 2009 21:45:53 -0400
To: Axel Polleres <axel.polleres@deri.org>
Cc: RIF WG Public list <public-rif-wg@w3.org>
Message-ID: <20090517214553.09697f51@kiferserv>
So, then it has nothing to do with the actual definition of a symbol space, but
is rather a name for an associated builtin and should be discussed there. 

This thing came up in Stella's review of FLD. It confused her and when I looked
at it it confused me. The problem is then with the way it is described (as part
of the definition of symbol spaces).


On Mon, 18 May 2009 01:43:59 +0100
Axel Polleres <axel.polleres@deri.org> wrote:

> Michael Kifer wrote:
> > I just became aware of the existence of "short names" for symbol spaces in DTB,
> > which was added without discussion and makes no sense. What is it, what is the
> > logical status of that beast, and why were they introduced?
> It was discussed.
> The short names are just a vehicle for the naming-convention of the 
> guard and negative predicates, because we cannot "encode" the full 
> datatype-IRI in the guard predicate name.
> An earlier version of DTB didn't use shortnames, but was trying to 
> define the nameing convention for guards in terms of the "trailing 
> NCNAME" of the datatype-IRI.
> In fact, this naming convention was discussed at the last f2f (browse ab 
> bit down after
> http://www.w3.org/2005/rules/wg/meeting/2009-04-16#datatype_IRIs_etc_break__2d_in)
> I had proposed a different naming convention for guards, i.e. using a 
> binfary predicate that uses the datatype itself as pred. name i.e.:
> DATAYPEIRI( value, true)
> for the positive guard and
> DATAYPEIRI( value, false)
> for the negative guard.
> That isn't as readable, but doesn require shortnames for the datatypes.
> Anyways, this proposal didn;t find a majority.
> the short names aren't used for anything else but for the guards.
> Axel

    -- michael
Received on Monday, 18 May 2009 01:46:37 UTC

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