Re: ACTION-384 completed: Post a use case for Higher-order builtins

>> It seems to me that this is an issue for phase 2:
>> - I do not think there are many systems which support this kind of
> built-ins
> 
> well, aggregates are supported by many languages (SQL, XQuery, etc.)
> and of crucial importance. It is just a more general definition of
> built-ins, fully upwards-compatible to simply saying "predicates with a
> fixed interpretation". I see no reason to preclude it if we can accomodate
> it by a slightly more general notion of built-ins.

The languages you mention are query languages; not rules languages. Are
there any rule systems besides dlvhex which support such general built-ins?

> 
>> - as I understand it, the implementation of such built-ins is far from
>> trivial
> 
> not so hard either.
> 
>> - because time is short, I think we should not start introducing new
>> features in the language, but rather concentrate on finishing the
>> features we agreed upon so far.
> 
> It is important to avoid lock-in against such features though.

it would be good to leave the option open for possible future extensions.

Best, Jos

> 
> Did you answer this to me only, or to the list?
> 
> Axel
> 
> 
>> Best, Jos
>>
>> Axel Polleres wrote:
>>> Hi all,
>>>
>>> I was asked to make a use case for what is called higher-order built-ins.
>>>
>>> In order to recap, let me repeat a generic definition of the term
>>> "built-in" from one of my previous mails (see
>>> http://lists.w3.org/Archives/Public/public-rif-wg/2007Nov/0011.html):
>>>
>>> "[...] evaluable predicates, unlike usual definitions of built-ins in
>>> logic programming, can not only take constant parameters but also
>>> (extensions of) predicates as input. Inputs can not only be terms, but
>>> also predicate names (in which case the *extension* of the respective
>>> predicate is the input.)"
>>>
>>>
>>> Here some example:
>>>
>>>
>>> 1) Aggregate functions, for instance count seem to be a necessary
>>> prerequisite for aggregating not only database data, but also web data:
>>> In this example, we assume we have a builtin &count with binding pattern
>>>
>>>   &count( Input, Output)
>>>
>>> available that counts the extension of the predicate 'Input'. With such
>>> a predicate, I could count the number of foaf:knows links defined in my
>>> foaf file more or less like this:
>>>
>>>     myfriends(?X) :- :me[foaf:knows->?X].
>>>
>>>     friendscount(Count) :- &count( myfriends, Count ).
>>>
>>>   Such builtins ar implemented in the dlvhex system [1,2]. We used this
>>>   generic mechanism for instance to implement an extension by aggregate
>>>   functions for SPARQL, details see [3,4]. In that paper we have more
>>>   complex agregates where we can also define the parameters of a certain
>>>   predicate we want to agregate over.
>>>
>>> 2) Another example is interoperability of rules and ontologies by
>>> dedicated DL query predicates, see also [1].
>>>
>>>
>>> 1. 1. T. Eiter, G. Ianni, R. Schindlauer, H. Tompits. A Uniform
>>> Integration of Higher-Order Rea-
>>> soning and External Evaluations in Answer Set Programming. In
>>> International Joint Con-
>>> ference on Artificial Intelligence (IJCAI) 2005, pp. 90–96, Edinburgh,
>>> UK, Aug. 2005.
>>>
>>> 2. http://www.kr.tuwien.ac.at/research/dlvhex
>>>
>>> 3. A. Polleres, F. Scharffe, and R. Schindlauer. SPARQL++ for mapping
>>> between RDF vocabularies. In OTM 2007, Part I : Proceedings of the 6th
>>> International Conference on Ontologies, DataBases, and Applications of
>>> Semantics (ODBASE 2007), volume 4803 of Lecture Notes in Computer
>>> Science, pages 878-896, Vilamoura, Algarve, Portugal, November 2007.
>>> Springer.
>>> http://www.polleres.net/publications/poll-etal-2007.pdf
>>>
>>> 4. http://www.polleres.net/presentations/20071127-SPARQL++ODBASE2007.pdf
>>>
> 
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
If you live to be one hundred, you've got it
made. Very few people die past that age.
  - George Burns