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

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

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?

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

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

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

???

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


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

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

???

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

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

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.

It is the authority which is making the claims, yes. But it is the
self-referential interpretation of the triple that determines if the
graph is to be taken as asserted or not.

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.

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.

These are two distinct tests.

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

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.

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.

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.

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.

Patrick

--

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

Received on Wednesday, 17 March 2004 04:19:57 UTC