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

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?

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

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

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

Pat


>it is certainly easier and the 80/20 rule seems to suggest we should.
>
>Jeremy


-- 
---------------------------------------------------------------------
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 Monday, 15 March 2004 10:57:41 UTC