W3C home > Mailing lists > Public > public-linked-json@w3.org > May 2013

Re: RDF WG Resolutions

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 15 May 2013 22:51:58 -0400
Message-ID: <519449CE.3000701@w3.org>
To: William Waites <wwaites@tardis.ed.ac.uk>
CC: richard@cyganiak.de, gregg@greggkellogg.net, public-linked-json@w3.org, public-rdf-wg@w3.org
On 05/15/2013 01:31 PM, William Waites wrote:
> Apologies for not making the meeting. Edinburgh would likely take the
> opposite view and support blank nodes as graph names. This is not
> really a last minute addition, it has been something that we have
> advocated from the beginning on the grounds of consistency -- fixing
> this now simply means it doesn't have to be fixed in a future
> iteration of the standard. I am pleased that the WG has decided to
> reverse the earlier decision to disallow this. Since blank nodes act
> as variables in the SPARQL I don't think there is a serious
> inconsistency.
> One thing that is not clear to me is whether this means that the
> "default graph" is still a special case, or if it is just another
> graph that could be referred to by statements through a bnode.

I don't think blank-node-graph-names bears on the default graph being a 
special case.

Personally, I think it makes a lot of sense to a have a default graph 
for datasets in general just like it does in SPARQL. Sometimes you want 
a graph and you're given a dataset, so ... which graph in the dataset 
should you get?  In JSON-LD this is explicit. Perhaps we should make it 
so for RDF in general.  (I would support that.   It helps the idea of a 
default graph make more sense.)

In my current coding, datasets are just sets of quads, and if the fourth 
field is 'undefined' (this is JavaScript, where 'undefined' is a 
null-like thing), then the triples is in the default graph. Seems pretty 

      -- Sandro

> Cheers,
> -w
> On Wed, 15 May 2013 18:10:55 +0100, Richard Cyganiak <richard@cyganiak.de> said:
>      > It is likely that DERI will formally object to the resolution to
>      > allow blank nodes as graph names. It's not required to fulfil
>      > RDF-WG's charter, throws RDF and SPARQL out of alignment, and
>      > has significant implementation costs. This is something for a
>      > future N3 working group, not something that should be added at
>      > last minute before LC.  Richard
>      > On 15 May 2013, at 17:10, Gregg Kellogg <gregg@greggkellogg.net>
>      > wrote:
>      >> We have two resolutions from the RDF WG today:
>      >>
>      >> The first is a resolution to allow Blank Node identifiers to be
>      >> used as graph names. If this stands, it resolves an at-risk
>      >> issue:
>      >> https://www.w3.org/2013/meeting/rdf-wg/2013-05-15#resolution_2. We
>      >> shouldn't try to remove this from the LC2 document yet, as the
>      >> last word may not have been said on this.
>      >>
>      >> The second resolution allows us to publish
>      >> https://dvcs.w3.org/hg/json-ld/raw-file/default/spec/WD/json-ld-api/20130516/index.html
>      >> as LC2 tomorrow:
>      >> https://www.w3.org/2013/meeting/rdf-wg/2013-05-15#resolution_3.
>      >>
>      >> The assumption is that, prior to PR, we will resolve the newly
>      >> introduced useNativeTypes issue by moving the flag from fromRdf
>      >> to expand, with a pass-through from other algorithms. This
>      >> would put the application programmer in charge of using native
>      >> or canonical representations of numbers and booleans, and
>      >> eliminates any round-tripping issues. If expanding with
>      >> useNativeTypes=true, values with a numeric or boolean datatype
>      >> but a string representation would be converted to JSON numbers
>      >> or booleans, including xsd:decimal. If set to false, native
>      >> types would be transformed back to either xsd:boolean or
>      >> xsd:double values. Of course, we may want to tweak this some
>      >> more.
>      >>
>      >> Gregg Kellogg gregg@greggkellogg.net
>      >>
Received on Thursday, 16 May 2013 02:52:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:53:22 UTC