W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: BLD: externally defined frames

From: Christian de Sainte Marie <csma@ilog.fr>
Date: Tue, 29 Jul 2008 20:12:56 +0200
Message-ID: <488F5DA8.8050203@ilog.fr>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:52 GMT