W3C home > Mailing lists > Public > public-rdf-wg@w3.org > April 2012

Re: blank nodes as graph labels

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
Message-ID: <1335727927.9663.859.camel@waldron>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 22:02:04 UTC