Re: Proposed draft RDF Graph vocabulary

>On Mar 17, 2004, at 01:53, ext Pat Hayes wrote:
>
>>
>>>On Mar 16, 2004, at 03:31, ext Pat Hayes wrote:
>>>
>>>>>>>     rdfg:Authority
>>>>>>>        a rdfs:Class ;
>>>>>>>        rdfs:comment "An authority, or origin, of a graph." .
>>>>>>>
>>>>>>>We don't say more about what an rdfg:Authority actually is. We only
>>>>>>>(vaguely)
>>>>>>>define that such a class of entities exist which have a particular role
>>>>>>>with regards to trust.
>>>>>>
>>>>>>"For example, a person or company."
>>>>>
>>>>>Sounds reasonable.
>>>>
>>>>BUt we need to be able to refer to the authority associated with 
>>>>a particular graph, in the MT.
>>>
>>>See the rdfg:authority and rdfg:assertedBy properties, which associate
>>>a member of the class rdfg:Authority with a graph.
>>
>>That is all just RDF formalism. The MT is supposed to be what says 
>>what this formal stuff means.
>
>Right. Again, I think we were simply talking past each other.
>
>>
>>>
>>>>formally we can say that the interpretation is relative to an 
>>>>'authority mapping' which interprets URIs denoting authorities to 
>>>>actual authorities, or some such trick. But I need real 
>>>>authorities in the MT somewhere.
>>>
>>>The 'real' authorities would be whatever are denoted by the URIs. So given
>>>
>>>    some:graph rdfg:authority some:authority .
>>>
>>>then whatever is denoted by some:authority is the actual authority of the
>>>graph denoted by some:graph.
>>>
>>>Right?
>>
>>Wrong.
>
>Then, again, maybe we weren't... ;-)

What I meant was, you stated the conditions for the graph to be true. 
So IF that graph is true, then yes, indeed. But just given the graph, 
nothing particular follows.

>
>>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.

>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.

>
>>
>>Now, we can specify in the semantic conditions that some URI must 
>>denote some actual things (agents, documents, whatever) in *any* 
>>legal interpretation (because we say so, just like we insist that 
>>typed literals denote datatype values): but to do this, we need 
>>some way to refer to those real things that is given outside of the 
>>RDF formalism itself (otherwise we are just being circular). So no 
>>amount of RDF vocabulary is going to provide this semantic 
>>anchoring, since until we get it anchored its just meaningless 
>>formalism.
>
>Yes. Agreed. So the way we get that semantic anchoring is by having some
>document somewhere (e.g. a MT or other document) specify how such URIs
>are to be interpreted. Right?

And the only way to do that is to write an MT for it.

>
>I.e. the documentation for swp:Authority, swp:authority, and
>swp:assertedBy says how folks are supposed to interpret the URIs
>in question.

OK, but the only way to do that is to constrain the MT.

>
>???
>
>>>
>>>I don't think we're introducing any new problems here.
>>
>>Not new problems, but we are asking our old tools to do new kinds of jobs.
>>
>>>Claims/statements about graphs or authorities or signatures are just
>>>claims, and they may be false, or lead to disagreements or contradictions,
>>>but testing of those claims or resolution of disagreements or contradictions
>>>will always be an extra-RDF activity.
>>
>>Well, but if the claims are about the RDF itself (as in 
>>reification) or about the process of publishing/asserting RDF, then 
>>one can reasonably expect that the RDF specs say something a little 
>>more about how the description relates to the reality described. I 
>>thought that was what we would be trying to do. IN cases like 
>>subGraph, we are talking about the syntax of RDF 'expressions' in 
>>RDF, so there is a special way to be 'wrong' which is 
>>syntax-checkable. I think we need to face up to our 
>>responsibilities to say more about this kind of a case.
>
>Fair enough. If you see a way to do this, then great.
>
>>
>>>
>>>To test if A rdfg:subGraphOf B is true or not requires comparing both
>>>graphs -- which is (I believe) not defined by the RDF MT as an explicit
>>>test by which one determines consistency.
>>
>>Not by the bare MT, no. But I wonder if in this case it OUGHT to 
>>be, in an appropriately extended RDFG MT. Think of how we extended 
>>the MT for datatypes, and imagine doing that kind of a number on 
>>the graphs. It is do-able, don't get me wrong.
>>
>>>To test if ex:bill is or is not the valid authority for an 
>>>asserted/published
>>>graph will involve PKI machinery or the like, which clearly is an extra-RDF
>>>process.
>>>
>>>To test if ex:sky ex:is ex:blue will require some extra-RDF determination.
>>>
>>>Again, I fail to see how we are introducing any new problems.
>>
>>Distinction. Finding out whether something is true is one thing. 
>>Making the question, is it true? be well-defined, is another. Do we 
>>want the question, "does this graph assert anything?" to be even 
>>well-defined? Does the semantics explain what it means, in some 
>>sense? It can do that without providing a means to test it. Or it 
>>can even punt on this issue, and just say 'asserted' is a property 
>>and I have no idea what it means (which is what it says right now, 
>>in effect). I'd be disappointed if we did that.
>
>So would I. I think that being able to ask the question "does this 
>graph assert anything"
>is pretty fundamental. At present, doesn't the RDF MT simply 
>presumes that every graph
>is asserted, if the graph is to have any interpretation at all? I.e. 
>it punts on the
>particular question, picking up just after a "yes" answer.

The current MT doesn't go into the matter. It just gives truth-conditions.

>
>
>>
>>>
>>>>OK, that is all just semantics. But what is the *utility* of 
>>>>being able to say this stuff in RDF? No amount of RDF vocabulary 
>>>>is going to actually get any asserting done or provide any 
>>>>signature security all by itself.  This seems to me to be like 
>>>>deciding how to talk about locks and keys, but not having any 
>>>>actual locks and keys.
>>>
>>>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.

>
>>>
>>>It's putting as much of the trust/authentication machinery into RDF space
>>
>>Unless we anchor the vocabulary, its not putting any machinery into 
>>RDF space.
>
>Well, my point was that statements using the new vocabulary have utility
>per the present RDF/OWL MTs, apart from that extra-RDF anchoring, but with
>that anchoring they have even more utility (and the essential utility we
>particularly need).
>
>>>Let me rephrase. The statement (potential claim) about assertiveness
>>>is provided by the rdfq:assertedBy property.
>>>
>>>Whether the graph is or is not considered as actually asserted
>>>by some agent depends on that special "bootstrapping interpretation"
>>>which is, agreed, outside the scope of the RDF MT.
>>
>>Well, OK. BUt then I really have NOTHING to do here (which may be a 
>>relief to all concerned :-). You don't need anything done to the 
>>MT: you are just inventing a user vocabulary and saying things in 
>>English about what its supposed to mean. Which is OK, let me hasten 
>>to add, but I thought we were supposed to be doing something more 
>>than that (Like, suggest a way to bootstrap trust and provenance.)
>>
>
>I think you still need some modification/extension to the RDF MT
>because (a) the RDF MT presumes assertion, and we are positing graphs
>which are published but not (necessarily) asserted (i.e. quoted graphs),
>and so (b) in order to interpret statements about assertion of a given
>graph in that same graph, it seems we need the/a MT to say how this
>is done.

The current MT doesn't mention assertion, so we have to say what assertion is.

>
>???
>
>>>For any graph where
>>>
>>>    ?graph ( ?graph rdfg:assertedBy ?authority . )
>>>
>>>then the graph denoted by ?graph is to be taken as asserted,
>>>by the authority denoted by ?authority.
>>>
>>>That, in a nutshell, is the bootstrapping interpretation for
>>>assertiveness.
>>
>>That isnt good enough, though, seems to me. All the semantic weight 
>>here is on the ?authority being actually the real authority, and we 
>>don't say what that means (never mind how to check it: we ought to 
>>at least explain what it is supposed to mean.) .
>
>OK. Please do.
>
>>On the other hand, the self-reference of the assertion plays no 
>>useful role: it doesnt help with authentication, and theres no 
>>semantic reason for it:
>>
>>?graph1 (?graph2 assertedBy ?authority)
>>
>>is just as easy to check, is more general, more useful and uses 
>>exactly the same semantics.
>
>I was limiting my example to the special, terminal case where the 
>asserting statement
>is in the same graph.
>
>Your counter example leaves open the question about whether ?graph1 
>is asserted/authentic.
>
>Without that self-reference, you have no way to terminate assertion chains.

They terminate in a graph which says that something is asserted by 
foo, and which is signed by foo. Its the authority that terminates 
the chain, not the self-reference. But read to end before responding.

>
>>
>>>
>>>It's extra-RDF in that, the RDF MT doesn't view the above triple
>>>as a triple if the graph is not asserted
>>
>>I really don't see how to make this coherent. A graph is a set of 
>>triples, and there is that triple in it. Is it in the set or not? 
>>If not, what's it doing in the syntax?
>
>I guess I was equating a triple as an asserted statement.
>
>Isn't it part of the formal definition of a triple that it is 
>presumed to be asserted?

No.

>
>So if you don't know if a graph is asserted (as opposed to just 
>quoted) you don't
>know if you have triples or just statements...
>
>But if I'm mistaken, please correct me (or just shoot me...)
>
>>
>>>  -- but the triple is
>>>what is asserting the graph.
>>
>>No, the ?authority is asserting the graph. It has to be the 
>>authority: if a graph gets itself asserted just by being 
>>self-referential then I can write an assertion spammer.
>
>I think we're blurring two issues: assertion and authentication.

I do not know what authentication means. Why are we distinguishing it 
from assertion? 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.

>
>It is the authority which is making the claims, yes.

OK: an assertion IS a claim (that a graph is true).

>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? What is the BASIS for this ruling? To me 
it seems like an arbitrary piece of decoration, like requiring that 
in order to be an assertion it has to be written in a ten-point font. 
But read to end before replying.

>
>If some spammer is publishing graphs which are attributed to some
>other authority, then (a) they are liable for all kinds of litigation,
>and (b) it is unlikely that any signature the spammer puts in the
>graph will actually authenticate per the supposed authority.

Fine. My feelings exactly: but note, its the signed identification of 
the asserting authority that does the work here. Self-reference is 
irrelevant.

>
>We really do need to keep these two things separate.
>
>One could first test authenticity. If the graph validates per the
>signature and the specified authority, then we can check if it is
>asserted (as opposed to just quoted) by that authority.

That depends on what the authority says about it, surely.

>
>These are two distinct tests.

Right. One is, what it says; the other is, whether the authority it 
claims to have (if it does so claim, ie if it says that some 
authority performs a web action) is real.

>
>>
>>>  Hence the appropriateness of the
>>>term "bootstrapping".
>>>
>>>The special MT needs to capture how the graph "asserts itself
>>>by its bootstraps".
>>
>>I don't want us to propose any way for any graph to assert itself 
>>without reference to some asserting agent. Its the agent that has 
>>to do the asserting, not the graph.
>
>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?

>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.

>
>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.

>
>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? There seems to be no need or rationale for this 
self-describing restriction; it would be very hard to impose 
semantically, and it serves no purpose.  BUt see below before 
answering.

>
>Eh?
>
>>>
>>>>
>>>>>
>>>>>We may even wish to find some other term than 'bootstrapping'
>>>>>(perhaps 'anchoring') to get further away from the phase/process
>>>>>connotations that bootstrapping drags into the mix...
>>>>
>>>>Yes, I like anchoring. Or, another term used for this is 
>>>>'grounding'. The meanings of this stuff have to be grounded in 
>>>>the real world of agency, assertion and trust somehow.
>>>
>>>I'm fine with you choosing some other term(s), so long as the
>>>end result is the same.
>>
>>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?)

>
>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? 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, though Peter will probably not like it.

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.

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

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

Received on Tuesday, 23 March 2004 15:42:20 UTC