- 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