- From: Sandro Hawke <sandro@w3.org>
- Date: Wed, 15 May 2013 22:51:58 -0400
- 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
natural.
-- 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:11 UTC