RE: Graphs: intension and extension

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

OK.

>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

I keep seeing references to what N3 does.  I will avoid commenting on 
N3 and whether or not to take it seriously, but is any of this stuff 
actually documented anywhere?

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

I have no problem with blank nodes REFERRING to anything, graphs 
included. But referring, and being used to identify, are not the same 
thing.  Using a blank node as a name or a label seems to me like 
talking about a hammer and expecting that to drive the nails in.

Look, its *logically valid* to substitute any bnode label for any 
other, as long as you do it systematically throughout the graph. So 
any use of a bnode to be a label is *logically invalid*.  No matter 
how lexically convenient it might be, that's a bad place to start.

I'll look at the paper tonight and get back.

Pat


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


-- 
---------------------------------------------------------------------
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 16:06:59 UTC