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

Re: blank nodes as graph labels

From: Pat Hayes <phayes@ihmc.us>
Date: Sat, 28 Apr 2012 20:14:13 -0500
Cc: Andy Seaborne <andy.seaborne@epimorphics.com>, public-rdf-wg@w3.org
Message-Id: <54B349F8-8A3B-4EB5-B1E3-20AC6695D9B6@ihmc.us>
To: Sandro Hawke <sandro@w3.org>

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?

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 01:14:52 UTC

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