SPAM-Re: Proposed draft RDF Graph vocabulary

On Mar 23, 2004, at 22:40, ext Pat Hayes wrote:

>>> I'll try to explain this again :-). Nothing is simply denoted by any 
>>> RDF graph, or by any URI because of an RDF graph. Denotation is 
>>> always relative to an interpretation. In one interpretation, it 
>>> denotes one thing, in another interpretation, another. As far as the 
>>> MT is concerned, all URIs could denote ascii strings.
>>
>> Yes, yes, yes. We went through this before. Did we not though conclude
>> that, insofar as "the common, global, shared, semantic web" which 
>> allows
>> folks to communicate about resources, that there is the presumption
>> (even if not guaruntee) that there is a shared interpretation of those
>> URIs -- we presume that they always denote the same thing no matter
>> who uses them in whatever graph -- insofar as the "Semantic Web" is
>> concerned.
>
> No. What we agreed on was that by sharing the names, we were all 
> agreeing to use them in the same way as far as the MT is concerned. 
> BUt all that means is, that any interpretation that satisfies me also 
> satisfies you, and vice versa. It does not mean that we have agreed on 
> a particular interpretation.

Right. I think we are pretty much in sync on this (i.e. I'm "satisfied"
with the above statement, even though I would not phrase things in that
particular fashion... ;-)

>
>> Yes, the RDF MT allows one to use RDF in other contexts and have other
>> interpretations, but the whole *point* IMO of the SW is to presume 
>> some
>> common interpretation of URIs and RDF graphs.
>>
>> Right?
>
> Wrong. Or at any rate, if that is the point, then the SW has to be 
> able to work miracles.
>
>>
>> (to that extent, I like the regrouping of those terms into a 
>> vocabulary
>> titled "Semantic Web Publishing" because it makes it clear that we are
>> talking about the semantic web (that presumption of a global, common
>> intepretation of RDF graphs) rather than just "arbitrary" RDF.)
>
> Sorry, this 'super-SW-RDF' is like Kryptonite. If it existed we could 
> leap tall buildings with a single bound. Trouble is, we can't.

OK, I'm probably using the term 'interpretation' incorrectly (again).

Let's just say that insofar as this global 'super-SW-RDF' is concerned,
we are all using the same URIs in the same way.


>>>> We are allowing folks to make claims in RDF about those locks and 
>>>> keys
>>>
>>> Only if we specify that the vocabulary actually talks about real 
>>> locks and keys, not just things that are called 'lock' and 'key' in 
>>> the vocabulary (which might be pieces of cheese and small blue pills 
>>> respectively.) The bare MT doesn't provide any attachment of a 
>>> vocabulary to real things. We need to add that if we want it done.
>>
>> Right. And that's what I was expecting the "new" or "extra" MT to do, 
>> to anchor
>> the special vocabulary in "reality".
>
> OK, good. Then as the author of the MT, I need to know how to talk 
> about this reality.
>
> Here's my current best take. We have to take some notions as given, as 
> primitive.
>
> 1. There are 'agents' or 'authorities' which can be identified by URIs 
> and which can be identified in some way as the owner of a graph. That 
> is, a graph (graph instance?) may be  'owned' by an authority. Exactly 
> how ownership is determined and checked is left open for now, but we 
> anticipate some kind of signature mechanism such as ....
>
> 2. There is a class of 'web performatives' which are actions connected 
> with an RDF graph which can be done by agents. These include asserting 
> and quoting. We do not mean to close off this class, and expect that 
> people will invent others. Each one has a recognized rdfg: name which 
> identifies it.
>
> 3. There is a basic rule, which our MT will formalize: if a graph is 
> owned by an authority and entails that the same authority performs a 
> performative, then indeed that action has been performed.  Ie. the 
> publication of a claim to perform *constitutes* a performance. This is 
> like how saying "I do" when asked "do you marry this person" 
> constitutes an act of marrying (Grice called these things 
> 'performatives': they include things like making a promise, asserting, 
> denying, giving orders by saying "I order you to...", and similar 
> self-fulfilling actions which are done by saying that you are doing 
> them.) So this is just borrowing a well-documented piece of speech act 
> theory and applying it to the Web.
>
> I think that is all we need, formally.

Right.

Will a MT taking this approach be able to deal with the special case
whereby in order to determine if (a) a graph is owned by a particular
authority, when claims about authority are made in the graph itself,
and (b) whether a given performance (e.g. assertion) is defined by the
graph itself, or does this presume that all claims about authority and
all performatives must be external to the graph.

I.e. does this approach cover the "bootstrapping" problem?

>

>> I think we're blurring two issues: assertion and authentication.
>
> I do not know what authentication means. Why are we distinguishing it 
> from assertion?

Authentication is the verification that (a) the authority exists and
one is able to obtain the information necessary for testing signatures
issued by that authority, and (b) testing a signature to verify that
(i) the signature was issued by the particular authority and (ii) the
signature identifies the graph in question.

All of the above is extra-RDF, based on information provided by RDF
statements.

> But OK, whatever; presumably then we can have graphs
> (A asserts B)
> (A authenticates B)
> and as long as they are each signed by A, then the appropriate 
> asserting or authenticating is in fact done. I'm happy with that.

OK.

>
>>
>> It is the authority which is making the claims, yes.
>
> OK: an assertion IS a claim (that a graph is true).

But what about when that claim about a graph is made *in* that
same graph? That's the bootstrapping problem.

If it's unknown whether the graph is true, then how do you know
whether the claim in the graph about the graph is true?

I am hoping for some mechanism (either via a MT or operational 
specification,
or whatever) which would allow an agent to determine, based on the
content of the graph whether that graph is valid per a given authority
and also whether it is asserted (contains claims by that authority).

>> But it is the
>> self-referential interpretation of the triple that determines if the
>> graph is to be taken as asserted or not.
>
> Why does B:(A asserts B) signed by A get something asserted, but B:(A 
> asserts C) signed by A not?

It would, but it may possibly only be a third-party assertion.

Let me give a more explicit example. Presume that all we have to work 
with are
the following two graphs:

B:(auth1 asserts B. auth1 asserts C. auth1 signs B).
C:(auth2 signs C)

Now, we have two authorities, auth1 and auth2.

auth1 is the publisher of graph B, which is explicitly signed and 
asserted.

auth1 is claiming, in graph B itself, that graph B is asserted.
(we accept this because the graph properly authenticates)

auth1 also, via graph B, claims that graph C is asserted.

auth2 is the publisher of graph C, which is explicitly signed.

auth2 does not claim that graph C is asserted.

Thus, graph B has first-party assertion yet graph C has third party
assertion (by an authority other than that specified in graph C itself).

An agent that trusts auth1 has the choice of either taking both graph B
and graph C as asserted -- or excluding third party assertions and 
taking
only graph B as asserted (ignoring the third party assertion of auth1
about graph C).

>> The graph is not asserting itself. No. The presence of a triple
>> put into the graph by some authority
>
> OK, good. So it is the fact that the triple is there because an 
> authority put it there, that gets the asserting actually done. Right?

RIGHT!

>
>> which is intended to convey
>> to agents that they should treat the graph as asserted is not
>> the same thing as the graph asserting itself.
>>
>> If I publish some graph with the statement
>>
>>    ex:John ex:loves ex:Mary .
>>
>> the graph is not claiming that John loves Mary. I am.
>
> Well, I think that what we could say here is that the graph 'says' 
> that J loves M, ie its true when J loves M (see the MT). By asserting 
> it, you are claiming that it is true, which amounts to claiming that J 
> loves M.

Right.

>
>>
>> If I publish some graph with the statement
>>
>> :X ( :X rdfg:assertedBy ex:Patrick . )
>>
>> the graph is not claiming that it is asserted by me, I am.
>
> Again: the graph SAYS that you are doing the asserting. It is true 
> when you are, in fact, asserting X: that much is just the current MT 
> meaning.  However, the fact that it is labelled X is irrelevant: it 
> would still be true, and for exactly the same reasons, if this graph 
> were labelled Y: the truth-conditions don't change when you change the 
> label. And if this graph is signed by you, and it claims to be about 
> your actions, then I see no reason to say that it is not asserted by 
> you. So if you sign a graph that says that you are asserting 
> something, then indeed you are asserting it.

So the above graph says that I am the authority of the graph and that
I am asserting (rather than just quoting) the statements in that graph,
and we determine whether the graph is true by authenticating the graph
per its signature. If it authenticates, then we treat the graph as true,
else we treat it as false and ignore it.

Eh?

>
>>
>> If one cannot authenticate the claims made in a given graph
>> because the signature doesn't validate for the particular
>> authority, then one simply rejects the graph. If it *does*
>> validate, then one considers the claims being made by that
>> authority as expressed in the graph -- and some of those
>> claims may be about the assertiveness of the graph itself.
>
> Fine, I agree with all of this. But why ONLY about the assertiveness 
> of the graph itself?

I'm not limiting it to just assertiveness. Note I said "some of those
claims", not "the only claims".

>>>>
>>>
>>> I think it isn't. The point of anchoring or grounding is that you 
>>> don't get to bootstrap. The authentication chain has to end in an 
>>> authority, not in a self-referential loop.
>>
>> I think we keep talking to cross purposes. There have been two 
>> issues/tests
>> that we need to account for (a) whether a graph is authentic, per a 
>> given
>> authority, and (b) whether the graph is asserted by that authority, 
>> or just
>> published by the authority with no claims actually being made.
>
> That latter is determined by what it says. It would be easy (though I 
> can see no purpose in this) to sign a graph which made no mention of 
> assertions or indeed of any acts by an authority, right? Deborah might 
> have signed the Wine ontology, for example. What would be achieved by 
> such a warrant, though? (That it is in fact the graph it claims to be? 
> But isnt that done by the labelling anyway?)

If Deborah wanted to simply indicate that she was the origin of that 
graph,
without (at that time) making any claims.

It may be that the graph has conditional assertion, and is not always 
considered
to be true, but she anyway wants it to be clear who the publishing 
authority
is.

>
>>
>> Yes, the authentication chain has to end in an authority -- and in 
>> particular,
>> in claims made about the authority of the graph expressed in the 
>> graph itself.
>>
>> And the assertion chains need to end in an authentic graph (and thus 
>> indirectly
>> in an authority) -- and in particular, in claims made about the 
>> assertiveness
>> of the graph expressed in the graph itself.
>
> WHY?? Why can they not simply end in an assertion about actions by an 
> authority, in a graph signed by that authority?

Sigh....

That final graph would have to both be signed by the authority and 
asserted
by the authority. I.e., the claims in that final graph about other 
graphs
would not be taken as claims if the authority doesn't assert the final
graph.

I.e. if you have some chain

:A (...)
:B (:A swp:assertedBy agent1. )
:C (:B swp:assertedBy agent1. )
:D (:C swp:assertedBy agent1. )
:E (:D swp:assertedBy agent1. )
:F (:E swp:assertedBy agent1. )

you still don't yet know if :F is asserted by anyone. To terminate this
assertion chain, you'd either need *special* extra-graph knowledge about
graph :F that it is in fact asserted, or you'd need to capture that
terminal assertion in graph :F itself. I.e.

:F (:E swp:assertedBy agent1. :F swp:assertedBy agent1. )

*Now* we've terminated the assertion chain.

> These actions can include asserting, warranting, denying, or indeed 
> anything. All we need to do is to identify a class of 'web 
> performatives' which are (expressed as properties of graphs with 
> agents as values and are) relations between a graph and an authority. 
> The basic MT rule is that the publication of a graph by an authority 
> which says that a performative is done, IS (by definition) a 
> performance of the act described. So this is like requiring people to 
> say "I, Patrick Sticker, do hereby assert/deny/query/warrant the 
> authenticity of/whatever, the graph named foo" in order to 
> assert/deny/etc things. I can write an MT for this,

OK. This sounds exactly like what I am wanting (and hopefully also 
Jeremy and Chris ;-)

So, per the above, the presence of the statement :F swp:assertedBy 
agent1. within graph :F
is taken to be a claim about graph :F (that it is asserted, and the 
asserting authority
is agent1) and the claim (or in fact, the entire graph) is taken to be 
true if the graph
authenticates per that particular authority (ie. the signature checks 
out).

Right?

> though Peter will probably not like it.

Cest la vie...

>
> Now, we could say that as a matter of good practice, so as to 
> completely remove any trace of doubt, it is a good idea to include an 
> assertion of the graph containing the performative itself., thereby 
> ensuring that a mere citation of a performative does not get counted 
> as a performance (??Not sure about that last point). So to assert G 
> (which is already published, say) absolutely unambiguously, following 
> this advice, I need to publish (and sign) a graph with two triples in 
> it:
>
> GW:( GW assertedBy Pat .
> G assertedBy Pat .)
> <signed by Pat>
>
> there by making my intentions abundantly clear. This of course 
> requires no further changes to the MT, since it just uses the 
> named-graph and asserted-by conventions we already have.

Right. And if that explicit claim about assertion 'G assertedBy Pat.' 
is omitted,
then while we may be able to confirm that Pat is the origin of the 
graph, we would
not be able to be absolutely sure that you are in fact asserting the 
graph, and
hence making the claims expressed in the graph.

I'd prefer to say that in the case that a graph is signed but not 
explicitly asserted,
that an agent should presume that the graph is not asserted but merely 
quoted by
that authority. Some other authority may choose to assert that graph 
via some other
graph, or even the original authority may assert it in another graph. 
But if you
only have that single graph alone, and there is no explicit statement 
about assertion,
then presume it is not asserted (even if signed and authenticated).

This gives us the quoting mechanism that reification fails to provide.

>
> Obviously, cast-iron legal agreements might require further checks, 
> such as having G be suitably signed and made secure against tampering, 
> things like that.

Right.

> I don't thikn we need to get into details of that, just as long as we 
> make sure it is possible without anything breaking (which I think it 
> is.)
>
> Would this be OK??

I think so. Yes.

(WHEW! ;-)

Patrick


>
> Pat
>
>
>>
>> Patrick
>>
>> --
>>
>> Patrick Stickler
>> Nokia, Finland
>> patrick.stickler@nokia.com
>
>
> -- 
> ---------------------------------------------------------------------
> IHMC	(850)434 8903 or (650)494 3973   home
> 40 South Alcaniz St.	(850)202 4416   office
> Pensacola			(850)202 4440   fax
> FL 32501			(850)291 0667    cell
> phayes@ihmc.us       http://www.ihmc.us/users/phayes
>
>

--

Patrick Stickler
Nokia, Finland
patrick.stickler@nokia.com

Received on Wednesday, 24 March 2004 03:32:24 UTC