Graphs: intension and extension

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
<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 ... 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 
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 - 
it is certainly easier and the 80/20 rule seems to suggest we should.

Jeremy

Received on Sunday, 14 March 2004 16:27:29 UTC