Re: Graphs: intension and extension

On Mar 15, 2004, at 17:57, ext Pat Hayes wrote:

>
>> Thinking about other aspects of the paper, I reckon a key choice is 
>> whether we
>> think of a graph intentionally (like an rdfs:Class) or extensionally 
>> like a
>> set.
>>
>> The Carroll/Stickler paper went for extension, it might however be 
>> better to
>> go for intension.
>
> Is this really ext/int, or is it the type/token distinction (here the 
> graph/document distinction, more or less)? It smells to me more like 
> the latter. If I assign a name to a graph, am I claiming naming rights 
> over the abstraction itself, or just over my instance of it?

IMO, just over the instance.

After all, someone else could assert the same graph. And if that graph 
had
first person assertion/authentication, then the third party would also 
be
affirming your claims regarding assertion.

E.g.

:X ( some:resource some:property some:value .
      :X rdfg:assertedBy ex:Bob .
      :X rdfg:signature "..." . )

:Y ( :X rdfg:assertedBy ex:Bill .
      :Y rdfg:assertedBy ex:Bill .
      :Y rdfg:signature "..." . )

Here, Bob is asserting graph :X. Bill is also asserting graph :X,
as well as graph :Y -- and by asserting graph :X he is agreeing
and affirming that Bob has asserted graph :X, as well as agreeing
and affirming the other statements in graph :X.

Thus, both Bob and Bill are referring to the same graph :X and asserting
that same graph :X, but Bill asserts graph :X in the first person while
Bill asserts graph :X in the third person.

Thus in a sense, graph :X is Bob's graph more than it is Bill's, and
this correlates to ownership/creation of the graph.

If the graph :X is authenticated, then that means that Bob has
published it and the signature checks out, etc.

It wouldn't be kosher for Bill to publish graph :X since he is not
the authority specified in the graph itself via which, in conjunction
with the signature, the graph can be verified. So while Bill can
affirm/assert graph :X, he does not own/control it, because any
authentication of graph :X in terms of Bill's keys would (likely) fail.

When determining trust, liability, etc. being able to distinguish 
between
who asserts/affirms a graph and who actually owns/publishes a graph is,
I think, very important.

Note that both Bob and Bill can publish distinct graphs which, aside
from the assertion/authentication statements, say the same thing. E.g.

:G ( some:resource some:property some:value .
      :G rdfg:assertedBy ex:Bob .
      :G rdfg:signature "..." . )

:H ( some:resource some:property some:value .
      :H rdfg:assertedBy ex:Bill .
      :H rdfg:signature "..." . )

but these remain *distinct* graphs since the differ in their 
first-person
assertion/authentication statements.

Alternately, we could have three graphs:

:Q ( some:resource some:property some:value . )

:R ( :Q rdfg:assertedBy ex:Bob .
      :R rdfg:assertedBy ex:Bob .
      :R rdfg:signature "..." . )

:S ( :Q rdfg:assertedBy ex:Bill .
      :S rdfg:assertedBy ex:Bill .
      :S rdfg:signature "..." . )

where there is no first-person assertion/authentication of :Q
and both Bill and Bob have an equal (third-party) relationship
to :Q.

An agent having a trust policy limited to authenticated first-person
assertions only would simply disregard :Q, regardless of the fact
that Bill and Bob both assert it.

>
>>
>> e.g.
>> if there is an RDF/XML document at http://example.org/x we can talk 
>> about
>> <rdfx:Graph rdf:about="http://example.org/x">
>>
>> we can annotate it with things like dc:creator
>>
>> we can compare it to other graphs with
>>    <rdfx:equivalentGraph> (graph isomorphism)
>> and
>>   <rdfx:subGraphOf> (understood as being isomorphic to a subgraph of)
>>
>> A blank node that names a graph is then just the usual existential ...
>>
>> The Carroll/Stickler paper also allows a blank node to be shared 
>> between two
>> graphs
>
> Ouch, I seem to have missed this. (Did I ever see a copy of this 
> version of the paper?? I don't seem to have it.)
>
>> ... this is seeming less than useful.
>
> Indeed, that is (forgive me) a terrible idea.
>
>>
>> Here is a test case in Chris TriG notation
>>
>> <a> ( _:a vc:name "Jeremy" )
>> <b> (_:b vc:name "Chris" )
>> <c> ( <eg> dc:creator _:a )
>> <d> ( <eg> dc:creator _:b )
>>
>> The problem is that <c> and <d> are equivalent, but if we accept all 
>> four
>> graphs they are saying different things. So if we accept some of the 
>> graphs
>> we need some mechanism for keeping track of which bnodes are which; 
>> which as
>> far as I can tell breaks more then we would want. I am currently 
>> inclined
>> just to prohibit bnodes to be shared between graphs,
>
> Right. That need not be a syntactic prohibition, only an understanding 
> that there is a need to standardize apart when combining information 
> from different graphs which both use a bnode.

I had always understood that bnodes are never shared between graphs, 
even
if one might infer that one bnode owl:sameAs another -- and that if two
graphs are merged, such that one graph has N bnodes and the other has M
bnodes then the merged graph will have N + M bnodes (even if the system
specific naming of those bnodes varies from graph to graph).

Yet, if some resource is denoted by some bnode, and that graph is merged
with another, then the resource remains denoted by the "functionally 
equivalent"
(even if having a new system identifier) bnode in the new graph.

If this is the case, then why couldn't a bnode denote a graph?

>
>>  except in the case
>
> I'd just have no exceptions, frankly. Why do you need to involve 
> bnodes at all? Bnodes aren't supposed to be names of anything; that is 
> the whole point of having bnodes in the first place.

Well, not names, but still a means to refer to a distinct resource.

>
>> where
>> the bnode names a graph and occurs (in a triple) in exactly one 
>> graph; in
>> this case it is basically required to remember the graph named by the 
>> bnode
>> ...
>>
>> The point of the example I guess is that the bnode _:a is playing a 
>> role in
>> linking two triples; the main reason for having those two triples in 
>> two
>> graphs is that some people might accept one of them without the 
>> other, which
>> then prevents the blank node from playing that role.
>
> It shouldn't. It is fine to infer (exists (x) P(x) ) from (exists (x) 
> (P(x) and Q(x)) )
>
>>
>> I guess a potential use for blank nodes shared between graphs is that 
>> I can
>> copy one of your graphs and then make additional statements with one 
>> of your
>> blank nodes in an additional graph of mine - I think we could just 
>> ban that -
>
> No, let it happen. As long as when I import your blank nodes, they 
> become my blank nodes, there is no harm in this and it might be 
> useful.
>
> Don't mess with blank nodes: we had them completely understood, and 
> they are totally debugged by 60 years of close attention from the 
> logicians. All we have to do is to stick to the idea that they are 
> bound in a graph, and have no connection with any names in any other 
> graph. Use URIs for any naming process larger than a graph (including 
> naming the graph.)

So, let me try to rephrase this as,

If you have two graphs A and B and graph A has K URIs and graph
B has K URIs and the set of URIs for graph A are B are identical,
and graph A has N bnodes and graph B has M bnodes, then merging
the two graphs results in a new graph C with K URIs and N + M bnodes.

So for any bnode in graph A denoting a resource, there is a bnode
in graph C denoting that same resource -- even if the system-specific
identity of that bnode for graph A differs from that of graph C.

Thus, one can infer new statements about resources denoted by bnodes
in graph A after syndicating graph A into graph C.

Right?

Patrick


--

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

Received on Tuesday, 16 March 2004 02:38:28 UTC