SV: [RDF] Queries, filters, context, trust, and more.., part 2

[Jonas Liljegren]

Stefan Andersson <Stefan.Andersson@ullmans.com> writes:

> > Let's say that the person has a lot of phone numbers.  
> > 
> >  - A person could say that the number has changed.  The request should
> >    retrieve the latest number rather than the old incorrect number.
> > 
> >  - If the person stating that the number has changed is untrusted, we
> >    should instead retreive the previous number.
> 
> Actually - this is a case where a change in current affairs is definitive.
> If I change my telephone number, I wouldn't want anybody to use my old
> number, which now goes to some other poor soul.
> 
> I think that there are classes of changes. Something like:

Yes.

> * This is a correction of an erroneous fact. The past fact has never been
> correct. (I stated it, though. And that could be a relevant fact.)
> * This is an update. The past fact was correct, but as from now, the new
> fact will be valid. It is a new version with respect to _time_.

> * This is a total change or addition. The past fact and the new has nothing
> to do temporally with each other. It is a new version with respect to
> _function_

What do you mean here?




> An example:
> Case 1:
> I have phone number A. I kill it. I have no phone. Then I have a new phone
> number B.
> Case 2:
> I have phone number A. I add a new number B. Now I have two phone numbers.
> Then I kill phone A.
> Case 3:
> I have phone number A. I let the phone company change it inte phone number
> B.
> Case 4:
> I have phone number B.
> 
> Now. The factual representation of all the (in the end) equivalent cases
> will (most probably) be different. And think thru what happens when you
> query the cases at different points...
> 
> I think there is an implicit _intentional_ layer on top of this. There is a
> difference between these cases, not only in how far apart the actions are.

The most importent thing I'm trying to do now is to determine how the
data must be structured in order to efficiently handle these types of
filterings or queries.

We will hopefully find a generic representation that will work equally
well with any other sort of filtering.

The structure should handle resources with a large number of
properties. (In fact, there could theoreticaly be a infinite number of
properties.)  Most agents will only be intrested in a small subset of
the properties.  This means that interfaces should not have to send
all data to the service.  But it should still send data that would
probably be requested later.  - We have to remember if a property has
been imported or not. ... I think it's clear how to do that.

The other thing is the internal chaching of the properties.  There
could be any number of lookup tables. Each type of question will best
be presented in a specialized lookup table.  Somehow, we have to
dynamicly detect the common types of questions and build lookup tables
to handle them.

Any suggestions on how to do this?



> >  - If the previous number is restricted, we would have to accept the
> >    later untrusted number.  But we could also try to convince the
> >    service that we are authorized to recieve the restricted
> >    information.
> 
> This is the concept of inter-process _interaction_ - I'm currently working
> on getting small, relatively dumb, mobile thingies act more intelligent by
> means of _interacting_ with smarter, bigger, stationary thingies.

As I have written in a earlier post, I think I know how to do this: in
the form of exception resouce objects.  In practice this means that
there will be two types of responses: the expected and the
unexpected.  This solves the problem with how a requst for a literal
value string can return a counter-request for more information.


-- 
/ Jonas  -  http://jonas.liljegren.org/myself/en/index.html