- 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:12 UTC