- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 15 Mar 2004 15:06:56 -0600
- To: "Jeremy Carroll" <jjc@hplb.hpl.hp.com>, <patrick.stickler@nokia.com>, <chris@bizer.de>
- Cc: <www-archive@w3.org>
>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