Re: BLD: externally defined frames

On Fri, 25 Jul 2008 16:54:09 +0200
Christian de Sainte Marie <csma@ilog.fr> wrote:

> Michael,
> 
> Maybe we could take the opportunity of a slow summer to progress on the 
> issue of externally defined Frames.
> 
> As I wrote in [1], I understood, at F2F10, that an external frame was a 
> frame in an external data source. I did not like the idea of handling 
> the access to external data sources on a construct by construct basis, 
> but since you insisted and nobody else objected...
> 
> But the explanation in BLD seems to say, either that an externally 
> defined frame is a frame where the data model (slots etc) is externally 
> defined ("externally defined objects can be accessed using the more 
> natural frame-based interface" [2]), or that, when a Frame is external, 
> it is really the slot that is an externally defined method ("...could be 
> an interface provided to access an externally defined method..." [2]).
> 
> Both interpretations might be problematic: the first one would imply 
> that we deal with references to externally defined data models on a 
> construct by construct basis; as for the latter one, if it is the method 
> that is externally specified, then it seems that the slot should be 
> External, not the Frame...
> 
> Can you clarify, please

Yes, clarifying: I have only a foggy idea of what you are talking about :-)

I understand neither what is problematic in the above nor the difference
between what you call an externally defined frame or method.

FYI, a data model is, by definition, a set of types of relationships
that are required to be used in specifying data instances.
Wikipedia goes even further and adds to it
(http://en.wikipedia.org/wiki/Data_model).

So, a terminology mismatch here.

I cannot figure out what you mean by "deal with references to externally
defined data models on a construct by construct basis".

What you aparently do not understand is that whether we use a restricted subset
of forms or not, it is you, the modeller, who decides what to use and how, not
the external source. If you want to model me and other people as tuples in a
relation

p(m,k,123456789)

all the power to you.  If I want to model you as an object in my application,
RIF allows me to:

csma[id->987654321, last->dsm, first ->c] 

But if I do not want to, I can model you (and other people) as above:

p(c,dsm,987654321)


	--michael  



> Cheers,
> 
> Christian
> 
> [1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0028.html
> [2] http://www.w3.org/2005/rules/wg/draft/rif-bld/#Terms
> 
> Christian de Sainte Marie wrote:
> 
> > Chris Welty wrote:
> > 
> >>
> >>
> >>
> >> Michael Kifer wrote:
> >>
> >>> The purpose of using external frames is exactly the same as that of 
> >>> using
> >>> external predicates. It is just a different interface. It can be 
> >>> provided for
> >>> external objects, while external predicates is an interface for the 
> >>> regular
> >>> (non-object-oriented) builtin calls.
> >>>
> >>> I would like to better understand what you and Christian had in mind. 
> >>> From the
> >>> F2F I understood that csma had right understanding of the purpose of 
> >>> that
> >>> feature. If the added wording is not what he expected then maybe it 
> >>> can be
> >>> improved (once I understand what is confusing there).
> >>
> >>
> >>
> >> I didn't quite get what Christian thought it meant, I hadn't thought 
> >> about it deeply but I guess I was expecting (based on your description 
> >> at the F2F which more or less sounded like your 1st para above) that 
> >> extern(s[p->o]) was syntactic sugar for extern(p(s,o)).
> > 
> > 
> > At the F2F, I had understood that an external frame was a frame from an 
> > external data source (something like a module). I did not like handling 
> > the access to external data source on a construct by construct basis, 
> > but since you were insisting...
> > 
> > But you explanation in BLD makes it sound like it is really a frame 
> > where the slots etc are externally specified (that is, refering to an 
> > externally dpecified data model). I do not like the idea of dealing with 
> > external (and user-defined) data model on a construct by construct basis 
> > either, and that interpretation is different from the previous one, 
> > which is disturbing.
> > 
> > Then, when we discussed that with Chris, I understood that he was 
> > thinking of external frames as externally specified methods: that is, 
> > frames where the slot key is an externally specified method (not just 
> > the name of an attribute). Which would be nice to have, but that would 
> > not be the frame that is external; and that understanding is different 
> > from the previous two, which makes the whole thing very confusing.
> > 
> > So, in the end, I was totally confused about what external frames are, 
> > and I think, with Chris, that the best option is to mark them AT RISK, 
> > so that we can discuss them, and change them if necessary, without 
> > having to come back to before LC.
> > 
> > Cheers,
> > 
> > Christian
> > 
> >>
> >> I'm not sure what to make of what it actually is, I need time to think 
> >> about it, and would rather not rush a final decision.  Again, the 
> >> proposal is to leave it as is in the BLD LC spec but put it at risk, 
> >> which gives us some flexibility to understand it.
> > 
> > 
> > 
> > 
> > 
> 
> 
>

Received on Friday, 25 July 2008 18:57:12 UTC