Re: symbol space short names

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

michael

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