- From: Christian de Sainte Marie <csma@ilog.fr>
- Date: Tue, 29 Jul 2008 20:12:56 +0200
- To: kifer@cs.sunysb.edu
- CC: Chris Welty <cawelty@gmail.com>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>
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:12:05 UTC