- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 12 Nov 2012 12:33:23 -0600
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: RDF Working Group WG <public-rdf-wg@w3.org>, Antoine Zimmermann <antoine.zimmermann@emse.fr>, nathan@webr3.org
On Nov 12, 2012, at 10:29 AM, Richard Cyganiak wrote: > On 12 Nov 2012, at 08:37, Pat Hayes wrote: >> +1 from me on "RDF Source". > > Okay, it seems most here can live with that term, which is encouraging. > >> FWIW, referring to my earlier response to Richard on blank nodes, this can also serve the role of my old terminology of "surface", so that we can say that bnodes (not bnode IDs, but actual blank nodes) are local to the RDF source in which they occur, i.e., no bnode can be in (graphs contained in) two different sources. This would clean up the current mess about the distinction between unions and merges of RDF graphs, and generally make more sense of bnodes. > > I see where you are coming from with this. > > I made some semi-coherent posts here a couple of weeks back about “blank node generators” or “blank node sequences”, which are similar in intent to your “surfaces”. When blank nodes were generated from the same “blank node generator”, then they are essentially on the same “surface”, and graphs involving them can be merged without needing to standardize anything apart. When blank nodes were generated from different generators, then they are on different surfaces, and in order to merge the graphs, some of the blank nodes have to be replaced with new ones so that all of them are from the same generator. In other words, one of the graphs first needs to be copied onto the new surface. Yes, exactly. We can use "scope" language or "generator" language and the result is the same. > > The RDF Source concept may not fully fit the notion of a “surface”. We want to be able to bundle multiple RDF Sources together (without copying/merging andything) and take a snapshot of that, and that would be an RDF Dataset. Hmm. Why can't we say that when you take the snapshot, you make a new source? > That's what happens in dumps of RDF crawls and similar use cases. And according to SPARQL Update, blank nodes can be shared between graphs in an RDF Dataset (although that wouldn't happen in the crawl use case Well, it might, and you would never know. :-) > ). This seems to indicate that blank nodes can be shared between RDF Sources. Hmm. There do seem to be two ideas here, indeed. One is something like the origin of the graph, I guess the original 'g-box' intuition, and the other is the current scope of bnodes. I think we have both been trying to keep these together into one notion, and it would sure be nice if we could. My favorite way to think about this is basically that you can't "move" a bnode. So whenever a source is probed (GET) or snapshotted, what you get is actually a new copy with new, freshly minted, bnodes in it. The "representation" of the (re)source that comes back as the payload of the 200-level HTTP response doesn't actually have bnodes in it, just a representation of their pattern in the graph, so when you use it to create your version of the graph, what you get is a new source with its own bnodes (marks) in it. It's the same (abstract) graph all the way through, but re-attached to many sources, with new bnodes every time. Does this picture make sense? Pat > > Or maybe there's just a missing something in the definition in the spec. > > Best, > Richard > > >> >> Pat >> >> On Nov 9, 2012, at 10:18 AM, Nathan wrote: >> >>> Antoine Zimmermann wrote: >>>> Yes, and I'm putting this resolution forward to feed the fresh discussion, and as a proposal to resolve the issue: >>>> PROPOSAL1: the notion informally known as "g-box" will be called "graph container". >>>> Alternative: >>>> PROPOSAL2: the notion informally known as "g-box" will be called "RDF container". >>>> Alternative (cf. Kingsley's email on the topic): >>>> PROPOSAL3: the notion informally known as "g-box" will be called "RDF document". >>>> Alternative (cf. Kingsley's other email on the topic): >>>> PROPOSAL3: the notion informally known as "g-box" will be called "RDF source". >>>> Personal vote: >>>> -1 for RDF document. Mostly shrug on any of the remaining 3 options but a slight preference for one of the first 2 choices. >>> >>> +1 for RDF Source, as RDF Container may be confusing in the context of LDP, RDF Document indicates the RDF is static, and graph container doesn't indicate that the things has changing states. >>> >>> >>> >> >> ------------------------------------------------------------ >> IHMC (850)434 8903 or (650)494 3973 >> 40 South Alcaniz St. (850)202 4416 office >> Pensacola (850)202 4440 fax >> FL 32502 (850)291 0667 mobile >> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes >> >> >> >> >> >> > > > ------------------------------------------------------------ IHMC (850)434 8903 or (650)494 3973 40 South Alcaniz St. (850)202 4416 office Pensacola (850)202 4440 fax FL 32502 (850)291 0667 mobile phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
Received on Monday, 12 November 2012 18:33:53 UTC