W3C home > Mailing lists > Public > www-archive@w3.org > March 2004

RE: Graphs: intension and extension

From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
Date: Mon, 15 Mar 2004 18:13:17 +0100
To: "Pat Hayes" <phayes@ihmc.us>, <patrick.stickler@nokia.com>, <chris@bizer.de>
Cc: <www-archive@w3.org>
Message-ID: <BHEGLCKMOHGLGNOKPGHDIENDCCAA.jjc@hpl.hp.com>


Pat,

the abstract syntax section of the first version of the paper is the most
finished and captures my current understanding of the treatment of blank
nodes, including the "blank nodes naming a graph" part, and blank nodes not
being shared, can you quickly review that and say what you think needs to
change.

Let's leave until after we've done the semantics the single issue of whether
blank nodes can or cannot be shared across graphs in the abstract syntax -
since we seem to agree that if we permit it, it has no semantic impact.
So once we've finished the semantics, we can experiment with removing the
constraint, and see whether we want to keep it or not.


Answering one of your points:
> >  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;

the motivation was in part to capture what N3 already permits with its
formulae, that can be seen as unasserted graphs that are named with a blank
node, which then participates in one other graph (typical the top-level
one).


Also, not permitting existentials to refer to graphs might require an
excessive use of skolemization to assign arbitrary names. I think blank
nodes capture such arbitrariness better than any name.

Jeremy

(No further comments, yet)



> -----Original Message-----
> From: Pat Hayes [mailto:phayes@ihmc.us]
> Sent: 15 March 2004 16:57
> To: Jeremy Carroll; patrick.stickler@nokia.com; chris@bizer.de
> Cc: www-archive@w3.org
> Subject: 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 12:15:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:41 GMT