# Graphs: intension and extension

From: Jeremy Carroll <jjc@hpl.hp.com>
Date: Sun, 14 Mar 2004 21:42:35 +0100

Message-Id: <200403142142.35218.jjc@hpl.hp.com>

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.

e.g.
if there is an RDF/XML document at http://example.org/x we can talk about

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 ... this is seeming less than useful.

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, except in the case 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.

I guess a potential use for blank nodes shared between graphs is that I can