Re: (ISSUE-40) Builtins and logic functions in BLD

Michael Kifer wrote:
> Thanks Paula,
> 
> There is really no issue semantically and the order of the builtins does
> not matter for BLD. PRD might be a different matter, but PRD is not my
> department, and it is still not in a shape when it makes sense to spend
> time discussing builtins.
> 
> There is pragmatic issue for BLD, which boils down to the need to specify
> binding patterns (or modes) for invocation of builtins.  If a builtin is
> invoked by not binding the right arguments, semantically this means that
> the corresponding relation is infinite. But pragmatically the application
> should possibly return an error.
> 
> We could incorporate errors into the semantics, but I think it would be an
> unnecessary complication. Perhaps we should see what OWL people say on that
> matter.
> 
> Another problem is whether we should allow builtins to be represented as
> functions and not just predicates. Again, there is no problem with this in
> principle, but it complicates the model theory and I think we should not do
> that --- at least not in Phase 1.  It is easy, however, to define builtin
> functions as syntactic sugar (i.e., by translating them into predicates).
> 
> We discussed these issues on the mailing list -- primarily with Axel -- and
> I think he agreed. 

rolling up my RIF mails after some absence. Yes, I agree.

>The only unresolved issue is whether there should be
> special syntax for calling builtins.
> 
> Some people wanted a special syntax, like {foobar(123)} (or whatever).
> This has an advantage of simplicity, but some people did not like it
> because it looks ugly. 

I sugest:

foo(bar)  ... logical function or predicate in abstract
&foo(bar) ... builtin/external predicate

> Another problem is that {foobar(123)} and
> foobar(123) would then mean different things, and this is not nice.

I think this IS nice becaus it allows to use URIs as function names in 
one dialect which are builtins in another which we cannot prevent upfront.

> I made a proposal that we should treat builtins using the same mechanism as
> modules. For instance, if a builtin is defined in the XQuery/XPath library
> then we would refer to it as
> 
>     fn:dateTime(...)@http://www.w3.org/2005/xpath-functions

We don't have modules in Phase 1, do we?
Nonetheless this is n interesting proposal... remind's me a bit of
external (parsed) general entities in DTDs, which can be public or local 
(SYSTEM)... PUBLIC ones could be agreed libraries of builtins and
SYSTEM ones could be used as import mechanism for general modules...
however, I am not sure whether we want to go to the depth of DTDs...
don't know at all whether this is related, but just brainstorming on how 
modules could be realized in the XML syntax, especially if XML already 
provides a mechanism for something like that. I could be completely 
wrong that this is related... XML experts beat me up, pls, if so ;-)

> where fn is a prefix for http://www.w3.org/2005/xpath-functions
> 
> Since all external predicates must be told where they are defined (in which
> module, KB), builtins would be just one kind of the externals.

However, would that mean that external logical functions are not allowed?

> But the module mechanism has not been defined. There is no technical
> problem here, however. Just a matter of time.

ok, the other proposal discussed further down that thread was using IRIs 
solely. There, I still have the problem, and would still object.
 From a practical point of view e cannot preclude that someone uses a 
URI as a logical function which later on in another (otherwise 
upwards-compatible) dialect is used as a builtin. I don't like these 
unforeseeable clashes.

As for this one:
> Just like we want people to make rif datatype-extensible, we should allow
> partners to exchange rulesets that use their private libraries of builtins
> (which both partners know about).

But: datatypes ARE syntactically distinguished in RIF, right?

I will try to make a wiki page in builtin-issues (if not already 
existent)... post you later.

Axel

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Thursday, 6 December 2007 21:54:09 UTC