Re: Named graphs etc

On Mar 09, 2004, at 23:13, ext Pat Hayes wrote:

>>
>> One thought that occurred to me is that it might be cleaner/better to
>> bootstrap the trust architecture using a specialized vocabulary which
>> applies *only* to the graph in which statements using that vocabulary
>> occur.
>
> that is essentially a 'this graph' naming function, right? "This graph 
> asserts..."

Correct.

>
>>
>> This could also serve to allow folks to specify whether a graph is
>> asserted or not.
>
> I'm coming to think that we need to provide for separating out a graph 
> from its assertion. Example: A publishes and asserts a graph, but B 
> wants to refer to it without (re) asserting it (maybe B wants to argue 
> with it). So B must be able to refer to the graph and its content 
> without referring to the assertion of the graph. So there has to be a 
> conceptual distinction between the published (named) graph and its 
> assertion.
>
> (Quick side question: do named graphs allow one to publish a reference 
> to a graph without publishing the graph (never mind about asserting)? 
> that is, can I say " a graph called "ex:myprivategraph" exists but I'm 
> not going to show it to anyone" ??)

I don't see why not. People frequently refer to their private
parts and make claims about them without whipping them out
in public ;-)

>
> Back to main thread. But unless we prove for some kind of 
> publish-as-assertion, we can't get off the ground. So, suggestion 
> (putting together various ideas, including Patrick's below):
>
> 0. Asserting is a relationship between documents (? resources? agents 
> who publish documents? owners of resources? whatever....) and graphs.
>
> 1. Primitive asserting is done by (publishing) a document with an 
> asserting tag.  and which which contains a(n instance of a) graph. 
> That document asserts that graph.  You need an asserting tag to get 
> the whole process started, so asserting isn't something that can 
> happen by accident.

Right. Though

(a) I think/hope that a specialized vocabulary could be used in the 
graph
instead of in the serialization

(b) I'd like to see the machinery generalized to graph qualification of 
any
kind, including assertion, authentication/signing, scope/context, 
precision,
etc.

> 2. But, in addition, one asserted graph can assert another graph, by 
> reference using the name. In this case the asserter of the first graph 
> asserts the named graph.

I don't buy this. Allowing one graph to assert another allows one 
person to
modify the intended purpose of someone elses graph. If I publish a graph
but do not assert it. Nobody should be able to publish another graph
having a statement asserting my graph.

This is why I limit the interpretation of that special boostrapping
vocabulary, members of x:GraphQualificationProperty, to the graph
in whch they occur.

The x:thisGraph term may prove too troublesome, and we may have to
require explicit graph naming and explicit use of graph names, but
still, qualification of a graph should be limited to the graph (or
document by which the graph is published) and not allow "infection"
from other graphs.

This should be a fundamental principle of the boostrapping machinery:
all graphs stand alone insofar as their qualifications are concerned.

> So I can assert something that is published and named, even if the 
> thing I'm asserting wasn't asserted by its own publication. Someone 
> else can deny it, maybe, and someone else can say something about it 
> without taking any particular stance towards asserting or denying it. 
> The graph expressing the content is just sitting there being referred 
> to.

Nope. Don't like it.

>
> Note, if A asserts B and B asserts C, A does not necessarily assert C. 
> Assertion is only done explicitly, not by transitive closure.

Eh? So, if I'm reasoning over some set of graphs A, B, and C, I have to
keep track not only of whether A, B, or C are asserted but *how* they 
are
asserted, and perhaps one conclusion follows per statements in A but 
don't
follow per identical statements in C because of where/how each graph was
asserted? Yikes!

I think it would be far simpler, and more than sufficient, to allow the
authority of each graph to specify whether a given graph is or is not
asserted, and then build trust "filters" based on top of that 
foundation.

> On the other hand, if B says that A asserts C, and A asserts B, then A 
> asserts C; that is, assertion *by A* is transitive.  Also, if A 
> asserts B and B imports C, then A has asserted C.
>
> 3. A graph can do both things at once, if it wants to. That is, it can 
> be asserted with a tag, and it can say of itself that it is asserted. 
> This is a very unambiguous way to assert yourself.

Why couldn't it simply say of itself that it is asserted, and we can
do away with the need for the tag/attribute entirely?

>
> It can also, BTW, say of itself that it does not assert itself, which 
> is odd but not paradoxical, since asserting isn't transitive (unlike 
> importing). Even if A does not assert itself, B can assert it; and 
> this can make sense even if A and B are the same asserter (eg owned by 
> the same owner doing the assertion.

I still don't like external assertion. True, a given agent can pretend 
that a graph
is asserted, regardless of what the owner of the graph says, but that 
is different
from actually affecting the assertiveness of a graph in general by 
agents syndicating
numerous graphs and not realizing that one graph asserts another graph, 
which otherwise
would be disregarded by the agent as unasserted...

I think here be lots of dragons...

>
> The only contradictory case is a graph *tagged as asserted* which says 
> explicitly that it does not assert itself. And in this case we could 
> just say that this is an assertion of a contradiction, and assertions 
> of contradictions are content-free. Note this is not a logical (= 
> RDF-semantic) contradiction, since the crucial asserting tag isn't 
> visible from within the RDF itself.

Yet if we simply do away with the tag/attribute, then such 
contradictions would not occur.

>
> 4. An assertion can be done by a pair of graphs, A which expresses the 
> content (and is not asserted) and B which asserts A and is asserted, 
> as in 2. above. But also, this can be modified/extended so that A tags 
> B as its warrant, providing a kind of secure external assertion, a 
> warranted handshake. Note that since each refers to the other, the 
> warrant can only be used once in this case.

But if you only first had graph A, which is unasserted, then you could 
not IMO rightly
interpret the statements of A to get the reference to its warrant graph 
B, which then
asserts A.

I like the idea of warrants, as a means of stronger 
authentication/validation, but not
as a mechanism for assertion.

>
> ---
>
> All of these cases provide for a separation of content from assertion, 
> since  A can refer to B by name without being understood to re-assert 
> B; this allows A to express doubt about another assertion, say. (If A 
> wants to re-assert B, it can do so explicitly.)
>
> I think this provides for most of what anyone could want.

And a good bit of what we might not want ;-)

> It can take existing usage and fix it up without changing any graphs 
> (other maybe than to give them names: we can use their URLs for now 
> :-)

Yes, but it requires changes to RDF/XML, which is probably far more 
costly
than most other approaches -- in terms of process/politics/acceptance
rather than actual technical effort.

>>
>> Thus, the name of the graph is used in statements within that graph, 
>> and
>> statements using a special property, e.g. x:isAsserted would
>> only be interpretable if the subject of the statement is the
>> same graph containing that statement.
>
> No, let it work for any pair. Then B can assert A even if A doesn't 
> assert itself. Which makes perfect sense.

It makes sense, but I think creates far more problems then it solves,
per my comments above.

Patrick

--

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

Received on Wednesday, 10 March 2004 05:06:53 UTC