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.

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.

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?

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

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. Thus, the inclusion of the statement in graph :Y
is innocuous.

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.

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.

It's a simple as that.

Cheers,

Patrick

--

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

Received on Thursday, 11 March 2004 04:45:22 UTC