Re: Named graphs etc

>On Mar 10, 2004, at 19:00, ext Pat Hayes wrote:
>
>>>>You can't bootstrap assertion/trust/etc. by putting stuff in 
>>>>graphs. These are all ABOUT graphs, so for example if you don't 
>>>>trust graphs, then having them say 'trust me!!' isn't going to 
>>>>make you trust them more.
>>>
>>>I would consider the same argument to then be valid against an XML 
>>>attribute.
>>
>>No, because XML attributes aren't required to have truth-functional 
>>semantics, as RDF is. They can 'mean' anything.
>
>See my recent discussion about a distinct "bootstrapping interpretation" phase
>prior to a full RDF interpretation.
>
>I look at this bootstrapping phase as analogous to processing of XML 
>attributes
>prior to full RDF interpretation, but using statements.

But this isnt feasible. That is, it might be OK to use statements to 
express this, except that once you put stuff in RDF statements, it 
has to obey the very generic 'logical rules' of RDF-style assertions. 
So for example suppose you can *infer* such a triple from some exotic 
piece of RDF/OWL reasoning? There should be no difference in meaning 
between this and having it written right into the graph.

Talking about 'phases' sounds to me like wanting RDF to be more like 
a programming language. Sorry, too late for that. If its not part of 
RDF then its not part of RDF, even if it looks like RDF.

>If the boostrapping interpretation phase succeeds, then those bootstrapping
>statements should still be true and valid for the full RDF interpretation.
>
>>
>>>
>>>The point is that it is not the graph saying "trust me", but the 
>>>creator/owner/publisher
>>>of the graph -- presuming there is the machinery to bootstrap a 
>>>layer of authentication.
>>
>>But the whole RDF design is predicated on the possibility of 
>>triples being freely transmittable, mergeable with other graphs, 
>>etc. etc. So what happens to the triple "I assert foo" when it gets 
>>imported from my graph into your graph? It no longer refers to the 
>>owner of THAT graph.
>
>I think we need to require explicit graph naming, possibly even using URIs,
>to deal with issues of merging.
>
>If some bootstrapping statement has a particular graph as its subject, then
>if that graph is merged into another graph, (a) the statement will no longer
>be relevant for bootstrapping of the new graph since its subject won't be
>the same as the new graph, and (b) if the resultant graph is deemed 
>to be asserted
>and trustworthy by the agent, then the statement should in any case remain
>valid insofar as its qualification of the earlier merged graph.
>
>The bootstrapping tests are done at points of entry into an agent's knowledge
>base. If the bootstrapping succeeds, then they are later innocuous if merged
>into some other graph. Yet if the agent has a knowledge base that preserves
>graph membership of statements (quads, quintuples, whatever) then specialized
>trust machinery can continue to use those statements to filter its views
>of what is or is not relevant to a particular application.

Maybe. Im not convinced: and in any case this is a lot more of a 
change to RDf then, say, adding an XML property.

>
>I agree, though, that having any kind of wildcard such as x:thisGraph would
>add alot of difficulties without direct modification to the presently defined
>RDF merge operation and probably is best avoided.
>
>>
>>If we are going to put the 'asserting' into the RDF itself, then we 
>>need a way to refer to the asserter that is reliably preserved when 
>>triples (not just whole graphs) are transmitted across the Web. 
>>Seems like we need to use URIs.
>
>Perhaps. I'd think, though, that blank nodes should also suffice. The
>key is that the identity of each graph remains distinct no matter how many
>merges/extractions occur.
>
>That *should* be the case for blank nodes, yes?

No. Taking a blank node outside its 'home' graph is either 
meaningless or has to be regarded as taking a re-named blank node 
into the other graph. Its a bare existential statement.

>
>>
>>>If you have some statement, the interpretation of which is 
>>>constrained to the graph
>>>in which it occurs (and there are then some issues relating to 
>>>graph merging that
>>>need to be addressed, of course, see below) then that is, I think, 
>>>functionally
>>>equivalent to an XML attribute value expressed in the 
>>>serialization of the graph.
>>>
>>>Essentially you are qualifying the graph with statements about the 
>>>graph which are
>>>only relevant for that graph.
>>
>>Which breaks the Web architecture assumed for RDF, seems to me.
>
>Not at all. See below.
>
>>Graphs are only abstractions, and sets of triples can be merged or 
>>cut up at will by applications.
>
>Yes, but if a particular graph is modified in any way, it is no longer
>the same graph and any new graph should have an identity distinct from
>the original graph and thus any statements qualifying the original graph
>are irrelevant for any other graph and thus are innocuous if included in a
>new graph and represent no loss of information if omitted from the new graph.

OK, fine as long as we have URI-style names that really do identify 
graphs, and don't use indexical-style constructions like 'this 
graph...'

>
>If some agent syndicates knowledge from multiple graphs, it will perhaps
>test the assertiveness and authenticity/trust of those input graphs, do
>its modifications, and when passing along a new graph to some other agent,
>will qualify that *new* graph per it's own identity/credentials.
>
>So if graph :X has a statement
>
>    :X trix:asserted "true"^^xsd:boolean .
>
>and that statement is merged into graph :Y, so what. An agent determining
>the assertiveness of :X will not be looking at graph :Y. And an agent
>determining the assertiveness of graph :Y will disregard statements
>about other graphs.

But why would it? That is, the claim in this triple - that X asserted 
a graph - is still TRUE even if its in another graph asserted by 
someone else. And if its true, and someone is asserting it, what's 
wrong with that? Why should it be required to be ignored? I might 
want to reason about who is asserting what. Trust reasoners will 
probably have to reason about stuff like that; the agent-policy 
reasoners people are writing are doing stuff like this in OWL already.

I don't think it is feasible to say that a triple is true in one 
graph but not true in another.

>Thus, the inclusion of the statement in graph :Y
>is innocuous.

OK, but its still meaningful, so should not be required to be ignored.

Look, there's a basic point here. If we say that what makes an 
assertion genuine is that we can find out who is making it, and if we 
can find out who is asserting an "X asserts.." triple by looking at 
who owns the graph that it occurs in, then we don't need the "X 
asserts..." triple in the first place: it's redundant. We can take 
any graph and see who owns it, and they are doing the asserting: end 
of story. (We might want to allow a non-assert form of publication 
for things like test cases, but they are the minority.)  Or, on the 
other hand, if some such trick isn't reliable, then its not reliable 
for the "X asserts ..." triple either, since there's nothing to stop 
Y from saying "X asserts ...". You can't have it both ways. Either we 
have some way to check on who is saying what, and if we have that 
then we can apply it without any special vocabulary; or we don't, in 
which case the use of vocabulary to check who is making claims is way 
too fragile to be used.

>The semantics of the trix: vocabulary will make it quite clear that agents
>should not believe/trust any statements made about a graph which occur
>in another graph. And agents won't be able to effectively employ trust
>machinery without, I think, additional support for maintaining graph
>membership, so less capable (i.e. "vanilla") RDF/OWL applications won't
>be able to make anything of those statements anyway unless working
>exclusively on a graph by graph basis.

I think that the only genuinely secure way to do this will be to have 
the ultimate warrants of assertion to be physically secure, under 
trusted control. To do that effectively requires external assertion 
(A can assert B) since it seems to me to be extremely likely that A 
and B here will have conflicting network requirements.

>Agents who are savvy about the bootstrapping vocabulary may even choose
>to filter out such statements when doing graph merging, knowing that
>they are irrelevant to any graph but that within which they were
>originally asserted.
>
>>
>>>Now, when it comes to graph merge, the only trick bit I see are occurrences
>>>of a "wildcard" term such as x:thisGraph, which would probably 
>>>have to be mapped
>>>to either a blank node, or if the graph is named, to the explicitly defined
>>>name of the graph. If the knowledge store keeps track of which statements
>>>belong to which graphs (e.g. via quads rather than triples) then one can
>>>preserve all bootstrapping information even in a merged graph.
>>
>>Sure, but what about pieces of named graphs? What if I take a named 
>>graph, toss out half the triples, then merge the rest with a piece 
>>of another named graph?
>
>Then you have an entirely *different* graph, and any statements about
>the other graphs are irrelevant to the new graph, and thus innocuous.

But is this remotely plausible as a way to deploy information on a 
Web? Every single set of triples has to have a unique, traceable 
name? Every OWL reasoner has to generate URIs for every conclusion it 
generates? Its is one thing to say that one CAN name graphs, but this 
seems to require that every subset of triples ever contemplated needs 
to be given a unique name for all time.

Pat


>
>It's a simple as that.
>
>Cheers,
>
>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 Thursday, 11 March 2004 13:27:25 UTC