Re: what to make external (ISSUE-78)

Michael Kifer wrote:
> 
> 
> On Mon, 06 Oct 2008 19:34:47 -0400
> Chris Welty <cawelty@gmail.com> wrote:
> 
>>
>> At the F2F we had a lengthy but ultimately inconclusive discussion on what to 
>> allow in an external call:
>>
>> 1) ATOM
>> 2) ATOMIC
>> 3) ATOM | FRAME
>>
>> In a straw poll, one person objected to each choice, and there were 3, 6, and 2 
>> people resp. who preferred each choice.
> 
> I remember that csma did retract his objections to (3).

Good! In that case we can progress by leaving things as they are by
closing the issue.

> 
> 
>> While more people prefer choice 2, it would require re-doing last call.  1&3 
>> would not, as 1 is covered by external frames being at-risk, and 3 is the way 
>> the spec reads now.
> 
> I think we should do what is right and the LC consideration is not very
> important, if the change is relatively simple (which is what will be in this
> case).
> 
> I think the right thing to do is Atomic-Equal|Frame

Did you mean ATOMIC-Equal? ATOMIC includes Frame.

> 
> Why minus Equal? In principle equality does not matter here, but one should
> realize that External(a=b) does not imply a=b. So, I am afraid that some people
> will be confused.

This is one thing.  My reason for objecting to equality in externals is
the following:
= is a special logical symbol whose meaning (i.e., the identity
relation) is given by the logical language (i.e., RIF), like the
connectives and quantifiers.

> But maybe this is a non-issue.
> 
> I think the LC thing will need to be redone anyway, because of the problem with
> the External primitive, which we discussed: it should really have the remote
> site's IRI as an additional argument.

I see that this is going in the direction of a general querying
mechanism of external data sources, rather than built-ins (which was the
original motivation for Externals).
I would prefer to just stick with the built-ins in BLD and leave
possible external query mechanisms to extensions.

Best, Jos

> 
> 
> 	--michael  
> 
> 
>> Let's try and come to some sort of closure by email.
>>
> 

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
  - Donald Foster