- From: Sandro Hawke <sandro@w3.org>
- Date: Sun, 29 Apr 2012 15:32:07 -0400
- To: Pat Hayes <phayes@ihmc.us>
- Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-wg@w3.org
On Sat, 2012-04-28 at 20:14 -0500, Pat Hayes wrote: > On Apr 27, 2012, at 2:18 PM, Sandro Hawke wrote: > > > On Fri, 2012-04-27 at 19:54 +0100, Andy Seaborne wrote: > >>> Comments: I believe this definition is formally equivalent to the > >>> SPARQL definitions and the one in our draft, except (1) some minor > >>> terminology, (2) allowing blank nodes as graph labels, and (3) > >>> allowing blank nodes to be shared between the graphs. > >> > >> So why write a new definition? > > > > Well, several people have said they couldn't see, formally, how to share > > blank nodes between graphs. So I tried to address that. > > > >> All this does is mean that W3C has two > >> definitions of the same thing. > > > > My purpose here was to make very clear, among us, what we're talking > > about. I'm not proposing this as the actual spec language. > > > >>> I expect the idea of allowing blank nodes to be used as graph labels > >>> to be controversial, but I think it's important for convenience > >>> and to clarify the semantics in the face of possible dereference > >>> operations. I understand it presents some issues, including > >>> SPARQL compatibility. I propose we consider this AT RISK through > >>> CR and see how those issues pan out. > >> > >> It is a real shame that this proposal starts by being controversial when > >> there may be much to agree in it. > >> > >> "AT RISK" at this stage is signaling an open issue. > > > > Yes. I hoped by being explicit about the controversy, people could see > > past it if they didn't like it. > > > > I included it here because I was trying to make a short but complete > > proposal for a design that I believe addresses the (never quite > > explicit) requirements of the group. I think, once people have a > > chance to see how the proposal works, with the use cases, they'll agree > > that this is a worthwhile feature. > > > >> On the blank nodes, > >> > >> http://www.w3.org/2011/rdf-wg/meeting/2012-01-04#Issue__3a__should__2f_must_the_4th_slot_be_an_IRI__3f_ > >> > >> Can we start where there is most agreement which, as I understand it, is > >> IRIs for labels? > >> > >> It is then up to those who want bNode for labels to persuade everyone else. > >> > >> Let's take a strawpoll. > > > > Sure, after we understand the proposal, and people have a chance to > > understand the pros and cons. In particular: if you're strictly > > followintg the Linked Data princples, it's not clear to me how you refer > > to an RDF Graph in a dataset, unless you use a blank node. Do you want > > to tell people to use 303-see-other URIs for that? That seems like an > > awful lot (a prohibitive amount) of work for publishers. > > Well, suppose we took the following line. > > 1. RDF graphs are a pure theoretical abstraction. The actual data structures or documents that encode them - graph containers - are what get named. > 2. Graph containers are information resources which can be referred to by an HTML IRI without indirection. > 3. Some graph containers are fixed, read-only, cannot be changed. These are used to hold graphs which are considered to be archival and not to be changed, so one can informally identify such a container with the graph it contains. Call them rigid containers. > 4. a named graph is actually a named rigid graph container. > > Doesnt that get over the blank-node issue, as well as being closer to reality? Yes. I'm comfortable with this, I think. Not entirely sure the notion of "cannot be changed" can be made to work, or exactly what point four means, even though I have a pretty clear memory of how Kripke talked about 'rigid designators'. This is pretty much the approach I'm using with "Layers", as I hope you can see (when I post it and you find the time to read it). -- Sandro > Pat > > > > > > > -- Sandro > > > > > > > > > > > > > > ------------------------------------------------------------ > 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 Sunday, 29 April 2012 19:32:16 UTC