Re: BLD: externally defined frames

Christian,
it is neither of the three interpretations, Iif I understood what you meant.
I am saying once again: it is all about how you *****MODEL***** external
sources in your particular RIF document. It is PRECISELY the same as with
predicates. There is no magic or mystry here. It is all very SIMPLE.
You are just confusing yourself trying to find in there what is not anywhere
near that thing that you are looking at.

There is no such a thing as "an externally specified function".
RIF does not use any externally specified functions and it is not even clear
what this might mean. A particular system might use externally specified
functions *if* it has a mechanism to invoke them. But this cannot be assumed
about most of the systems, and RIF should not and cannot make such an
assumption.

When I model something my application, I have a choice of using different
constracts.  I can choose to use a predicate, a frame, a foobar. This has
little to do with how things exist externally. Think of a database system, for
example. DBMSs are not defined as objects by their vendors, but interfaces like
JDBC view them as such. This model, which is built into Java, has little to do
with how some Oracle engineers view their DBMS (or what this DBMS really
is). It has everything to do with how Java engineers view it.

Clear now?


	--michael  


On Tue, 29 Jul 2008 20:12:56 +0200
Christian de Sainte Marie <csma@ilog.fr> wrote:

> 
> Michael,
> 
> I think that what is confusing me, in your example to explain what are
> external frames (in section 2.2), is that the examples covers all three
> possible interpretations I mentionned:
> 
> 1. External frame = frame where the (instance) object is located in an
> external data source:
> External("http://example.com/acme"^^rif:iri[property->value])
> (where 'property' is not necessarily of type rif:iri).
> 
> Wrt my concern that we should not specify access to external data 
> sources on a per construct basis, I mean that the way an frame located 
> in an external data source (e.g. an object-oriented data base) is 
> "imported" should not be different from the way a relation located in an 
> external data source (e.g. a relational data base) is. I understood the 
> external atom more as being something like a boolean function; although, 
> of course, the specification of such a function could be wrt the content 
> of a DB.
> 
> So, maybe that concern of mine is a non-starter; but I feel 
> uncomfortable about it nonetheless :-(
> 
> 2. External frame = frame where the (instance) data model is specified
> externally (and has, therefore, to be interchanged out-of-band):
> External(object["http://example.com/mycompany/president"^^rif:iri->value]
> 
> and, object##"http://example.com/mycompany"^^rif:iri (where 'object' is 
> not necessarily of type rif:iri); that is, the
> instance data model says that there is a class of objects, named
> "mycompany", that have an attribute named "president", and that instance 
> data model is defined at IRI "http://example.com/".
> 
> 3. External frame = frame where the slot key is an externally specified
> function (which specification has to be known out-of-band):
> you write  "External(...) could be an interface provided to access an 
> externally defined method 
> ""http://example.com/mycompany/president"^^rif:iri" ...", which might 
> mean that
> External(object["http://example.com/mycompany/president"^^rif:iri->value]) 
> represents something like: object.president()=value, where the nullary 
> method "president" (or the equivalent fixed interpretation unary 
> function "president(object)") is specified externally.
> 
> I understand that options 2 and 3 are closely connected, since the
> method cannot have arguments in the proposed syntax, but they are still
> different, since interpretation 3 might seem to open the door to methods
> with arguments.
> 
> My question is: which one (or which ones) of these possible
> interpretations is intended?
> 
> Is the question any clearer, like that?
> 
> Cheers,
> 
> Christian
> 
> Michael Kifer wrote:
> 
> > 
> > On Mon, 28 Jul 2008 12:00:37 +0200
> > Christian de Sainte Marie <csma@ilog.fr> wrote:
> > 
> > 
> >>For the remainder of your reply: I have to think about it and try to 
> >>connect it with my request for clarification. I will come back to you 
> >>later...
> > 
> > 
> > Here is another way to put it.
> > 
> > One should see external frames as another degree of freedom of modeling: it
> > gives more constructs to enable modeling external sources in more ways,
> > including as objects, if that is what one wants. Without external frames, one
> > is *forced* to model external sources as relations, while other (internal)
> > things in the document might be relations or objects.  This is an unpleasant
> > and unjustified restriction.
> > 
> > Furthermore, RIF is an exchange language. If language A models some external
> > sources as objects and BLD only allows external relations, that language A must
> > do a one-way, non-round-tripable translation.
> > This is exactly the same argument as what we used for adding frames and other
> > stuff into the language. If it weren't for round-tripping and the ease of
> > translation for rich languages, we could have limited everything to just
> > positional predicates, and BLD would have been 1/2 its current size.
> > 
> > 
> > 	--michael  
> > 
> > 
> 
> 
> 
> 
> 
>

Received on Tuesday, 29 July 2008 18:33:49 UTC