[RDF] =?ISO-8859-1?Q?Trust_=28long=29_=5BWas=3A_M=F6te=3F=5D?=
Stefan Andersson
Stefan.Andersson@ullmans.com
Mon, 20 Nov 2000 10:43:39 +0100
> Men varf=F6r kan vi inte skriva p=E5 engelska f=F6r?
Sorry, I'll switch to english.
> Hur infererar man implicita staters?
'Implicit staters' have to be inferenced from some given logics, f.ex: =
'All
documents, and hence all contained knowledge, transferred via HTTP is
transferred to me by a HTTP daemon, and recieved by an HTTP agent.
Hence, I have placed implicit trust in the daemon and the agent by
implicitly trusting the interface by using it.
So, if I (A Perl language application) trust a certain statement, the
implicitly trusted instances are
* The Perl language (and implicitly the perl coder community)
* The application (trusting other parts of itself, and the ability to
function as a whole)
* The WRAF core module (and implicitly the coder of the module)
* The WRAF HTTP Interface support module (and implicitly the coder of =
the
module)
* The HTTP support module et.c.
* The HTTP protocol
* The web server daemon (What is its URI, by the way?)
* The web server file system
* The document (and the author(s) of the document)
* The model contained in the document
* In the case the document is a front-end for another database, there's =
the
database, the server application et.c.
And finally,
* The statements in the document itself.
So, OK, this look rather nit-pickingly silly, but actually, in some
applications, you will want to make _sure_ that these implicit trusts =
are
made explicit - and that all the instances are secured and monitored by =
an
authority.
But most of the times, you optimize by 'faith'. Why should I doubt the
Apache web server implementation of the HTTP protocol? Why should I =
doubt
wheter a server presenting itself as an Apache really is one?
So, I make implicit trust - a web server/HTTP daemon is trustworthy. =
End of
discussion.
But this implicit trust could be stated, thus making it explicit. 'All
resources of class 'HTTP daemon' are trusted'.=20
> > Det intressanta blir ju d=E5 i en 'omv=E4nd' situation, d.v.s. =
n=E4r det
g=E4ller
> > 'uppdatering' att det _egentligen_ g=F6rs ett antal nya statements, =
som
> > antingen kommer att ing=E5 i 'trust-m=E4ngden', eller inte kommer =
att g=F6ra
det,
> > d.v.s. man kan se p=E5 det som att vad man g=F6r, =E4r att man =
lokalt cachar
> > (eller etablerar lokala resurser) ett antal statements som kommer =
fr=E5n
en
> > anv=E4ndare, genom att man ser det som att anv=E4ndaren =E4r en =
'resurs' (som
> > lagras lokalt och f=E5r ett internt id) och att allt som kommer =
blir
'stated
> > by' denna resurs.
>=20
> Fick l=E4sa flera g=E5nger... Men jo. S=E5klart. Varje statement =
kopplas
> till vem som sagt det. Svarar p=E5 engelska i separat brev...
The main point, which I'm uncertain if you got, is that the incoming =
data
from a POST form update, should be seen as a temporary resource, =
existing
only in the recieving parts temporary memory, until a decision is made =
to
store (cache) the content (because you can be _certain_ it will never =
be
available again). And that content could never be seen as an =
'replacement',
only as yet another bunch of statements about things. Even if it is the =
same
source saying something new about something, you couldn't _replace_ it. =
Only
add it to your ever-growing database of statements. (a.k.a. =
'knowledge')
But: The reconciliation process could use statement meta-data, see Jos
example [1], to 'weed out' statements that are in conflict, untrue as =
for
current knowledge, seldom accessed, trivial, or explicitly outdated.
So, for each statement, you would need to state=20
* Source
* Wheter the statement nullifies another statement
* When it was made
* Wheter it will be available ever agin
* Wheter the statement is seen as critical and/or authoritative. =
(priority)
To optimize the amount of refences, you could connect a model (bunch of
statements) to a 'session' (everything stated by an agent at a certain
time).
Actually, a statement could both make a data statement, about a thing, =
and
at the same time make a schema statement. Come to think of it, this is
critical. You should be able to say:
M1: { Schema Model, stated 1999-05-01 by Stefan }
S1: Persons can only have one cellular phone number
M2: { Temporary Model, stated 1999-05-01 by Stefan }
S1: Stefans cellular phone number is 555-123456
M3: { Temporary Model, stated 1999-09-01 by Stefan }
S1: Stefans cellular phone number is 555-674534
[ Inferred S2: M3.S1 nullifies M2.S1 ]
M4: { Temporary Model, stated 2000-06-02 by Jonas }
S1: Stefans cellular phone number is 555-123457
[ Inferred S2: M4.S1 nullifies M2.S1 ]
S3: Persons can have many cellular phone numbers
S4: M2.S3 nullifies M1.S1
S5: Stefans cellular phone number is 555-123458
This will end with Stefan, after reconciliation, having two cellphone
numbers: 555-123457 and 555-123458, and that the schema now accepts =
multiple
phone numbers.
A completely different question is _how_ the agent should know that it =
has
to explicitly update the schema - but of cource the agent has to check =
the
schema to see how many numbers it should expect, so it should know.
And, the temporal _ordering_ suddenly becomes critical. Hmm. This is no
good. Obviously, the statements M4.S1-S4 and the statement M4.S5 would =
have
to be treated as stated at different moments in time.
But: The reconciliation should be _private_ - it's MY truth model that =
is
being reconciled. If I trust Stefan, but not Jonas, I will still think
Stefans number is 555-674534, and I will still think Persons can have =
only
one cellphone number. Which, of cource leads to interesting effects =
when I
get a new phone number...
... aaaand: What happens if I come to trust Jonas some time after the
statements have been made? :-D
(yep, this is why it is wise to 'remember' things even if you don't =
trust
them. And maybe the things Jonas says make you come to trust him...)
Further on: The 'reconciliation' is not only about after-processing, =
it's
about reconciling viewpoints. Therefore I have MY Schema model. And =
when I
interact with another entity, we will have to synchronize our schemas =
before
interacting.
> > 'Tempor=E4ra statements' som beskriver ett icke-tempor=E4rt
>=20
> Huh?
Ah, 'temporary statements', my word for statements that only exists as =
a
transaction. Web Form POST:s f.ex.
> > Dock =E4r det ju helt ointressant f=F6r systemet att beh=E5lla =
information,
> > statements, som ingen anv=E4ndare av systemet litar p=E5. Hmmm... =
jag tror
jag
> > snubblade p=E5 n=E5got h=E4r... men f=E5r fundera djupare p=E5 det =
vid tillf=E4lle.
>=20
> Jo. Visst =E4r det intressant. Man tror ju fortfarande kanske p=E5
> aspekter av det, =E4ven om man inte tror p=E5 allt. Exempelvis s=E5 =
=E4ven om
> man inte tror p=E5 ett uttalande s=E5 kan det vara intressant att =
veta att
> personen i fr=E5ga har gjort uttalandet. T=E4nk dig exempelvis en
> diskussionsgrupp. Inte tar man bort inl=E4ggen bara f=F6r att de =
inte =E4r
> troliga. Man =E4r intresserad av det =E4nd=E5.
>=20
> Bortfiltrering =E4r inte det enda svaret p=E5 untrusted statements.
> Uppm=E4rkning =E4r ocks=E5 intressant, s=E5 kan de presenteras p=E5 =
ett annat
> vis. Och h=E4r kan man ha m=E5nga olika sorter av untrusted =
statements.
> Det kan vara gamla, overifierade, anonyma, eller massa annat.
Yep. I think we've got a very interesting path going. I'm convinced =
that
'private reconciliation' is the way to go. But I also think that this =
means
a distribution of the data model to the end-client. A server =
reconciling
thousands of viewpoints... no way.
/Stefan
[1] =
http://lists.w3.org/Archives/Public/www-rdf-interest/2000Nov/0232.html
_____________________________________________________________________
Stefan Andersson
Senior Systems Developer
Ullman Communications
Johannebergsgatan 30
412 55 Gothenburg
E-mail: stefan.andersson@ullmans.com
Tel: +46-31-7082600 Fax: +46-31-205056 Cell: +46-733-404152