Manu Sporny: Some JSON-LD news, a graph database engine just put in native support for JSON-LD. The Activity Streams 2.0 work has adopted JSON-LD as a way of publishing activity stream data, which is great.

Markus Lanthaler: Link to graph database supporting JSON-LD: https://github.com/mcollina/levelgraph-jsonld

Manu Sporny: Discussion about Activity Streams 2.0 work using JSON-LD compatible format. Publishing JSON-LD context.

Manu Sporny: [discusses agenda items] we have an addition from niklas about what we should do with the flattening algorithm

David Booth: i wanted to propose a suggestion for how we deal with blank nodes as predicates as well

Manu Sporny: let's deal with niklas' flattening algorithm first then bnodes as predicates and then we'll deal with David Booth's issue and then review the other issues

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/276

Manu Sporny: this has to do with converting appendices into regular sections -- the primary argument for this is that the appendices are very normative sections and appendices may be considered "additional" info, so instead let's make them regular sections since a lot of normative stuff is in there

Dave Longley: i dont' think we should move them around (ordering), but changing them to regular sections is fine

Manu Sporny: yeah, the proposal is to leave them exactly where they are

Markus Lanthaler: i'd be fine with that change

Gregg Kellogg: the reference would be to dan connolly's advice which is that the doc should read the same if the appendices were removed

David Booth: +1 to Dan Connelly's advice

Manu Sporny: it would be A, B, and C, we'd leave appendix D the same

Gregg Kellogg: so there would be some movement because we'd move appendix D (it becomes appendix A) after appendix C

David Booth: +1

Dave Longley: +1

Manu Sporny: +1

Gregg Kellogg: +1

Markus Lanthaler: +1

Niklas Lindström: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/279

Manu Sporny: niklas has written up the "problem" with the current flattening algorithm, some see it as a good feature others see it as a bad feature

Manu Sporny: niklas has placed an interesting example into the tracker to demonstrate the downside of the current algorithm

Manu Sporny: so the question is whether or not we see this as a bug in the flattening algorithm or not, fixing the bug would result in not promoting things that are "leaves" -- things are only at the top level

Gregg Kellogg: the same thing goes for the fromRDF algorithm which generates the same footprint

Markus Lanthaler: is it worth changing at this stage if you can just filter the data out later?

Manu Sporny: my position is that we want to do whatever the majority of devs want, if they all have to filter this stuff out then we should probably have made things filtered out by default

Manu Sporny: i do think it's strange to have datatypes as nodes in a flattened graph and that it does make things a bit messy

Manu Sporny: i haven't experienced datatypes as nodes using other syntaxes/APIs/etc

Manu Sporny: i think it will be more rare to try and get the number of subjects vs. getting all the nodes flattened out so they can iterate through them

Manu Sporny: i think it's worth fixing it at this point since fixing it later would be more difficult, adding it would be easier later if we really need it

Manu Sporny: so i'd lean towards removing these extraneous nodes

Gregg Kellogg: if require our algorithms to have this data now we remove the ability to clean it up later because people will come to depend on it

Gregg Kellogg: should we mark this at-risk?

Gregg Kellogg: there's a danger that someone could argue this is a normative change, etc.

Manu Sporny: well, i think it's a bug and the other argument that it's not a substantive change because we're doing CR and the algorithms are really for review there and the true test is if CR implementors think this was a good change, etc. -- at this point this was a bug that was put in the spec that was part of a rewrite, we're putting it back how it was and marking it at-risk if implementors feel it should be done another way

Manu Sporny: sound reasonable?

Gregg Kellogg: yes

Gregg Kellogg: +1

Dave Longley: +0.5

Niklas Lindström: +1

Manu Sporny: +0.7

Markus Lanthaler: +1

Markus Lanthaler: how are we going to filter them out? leave them out of the node map or not?

Dave Longley: There is another reason we want to do that - the framing algorithm relies on the node-map algorithm, so we should have them in the node map. [scribe assist by Manu Sporny]

Gregg Kellogg: i think we used to do it with them in the node map and we just removed them later

Gregg Kellogg: i think there's no problem with adding things to the node map

Niklas Lindström: the node map is just an internal state, so when adding properties to things in the node map you add them to the array which is cleaner than filtering at the end, i think

Niklas Lindström: you can build the node map and the flattened array at the same time

Markus Lanthaler: http://json-ld.org/spec/latest/json-ld-api/#flattening-algorithm

Manu Sporny: would making that change complicate the algorithms?

Markus Lanthaler: For each id-node pair in graph ordered by id, add node to the @graph member of entry. State that node needs to have other properties than @id

Dave Longley: i don't think we should leak the flattening info into the node map algorithm because it complicates things, but we could mention the optimization

Markus Lanthaler: i think we only need to add some words to the flattening algorithm

Gregg Kellogg: fromRDF just removes some steps

Manu Sporny: markus, do you have an idea for what changes to make?

Markus Lanthaler: yeah, for flattening yes, i can look at the RDF one, shouldn't be too difficult

Manu Sporny: can you take a shot at that?

Gregg Kellogg: what about graphs with no data in it?

Manu Sporny: well there's an argument to remove it based on how people will use flattening

Gregg Kellogg: well, i think an empty graph is actually data and there's value in retaining that

Gregg Kellogg: i think there's value to keeping that information in a flattening representation

Dave Longley: There may be an additional problem here - there may be disjoint information in the graph. [scribe assist by Manu Sporny]

Dave Longley: If we remove them at the top-level, they'll cease to exist entirely in the flattened output. If there is no reference to something in the graph, we'll lose it. [scribe assist by Manu Sporny]

Dave Longley: This may be more complex than we want it to be - we have to make sure that the things we're removing aren't referenced from anywhere else. [scribe assist by Manu Sporny]

Markus Lanthaler: We already remove free-floating nodes, right? [scribe assist by Manu Sporny]

Niklas Lindström: An empty graph sounds like a covert delete to me. [scribe assist by Manu Sporny]

Gregg Kellogg: I don't think we can do that, you can't actually say in RDF that a graph is referenced. The name of the graph does not semantically relate to the use of that name in a triple somewhere else. [scribe assist by Manu Sporny]

Gregg Kellogg: The fact that a graph has a name and is free standing and not referenced does not have an impact on the RDF Dataset model [scribe assist by Manu Sporny]

Dave Longley: That's true, but we wanted to take a different direction in JSON-LD. It's more useful to say that the name of a graph does have meaning. As it appears in the JSON, it does seem to have meaning. [scribe assist by Manu Sporny]

Niklas Lindström: We can leave it as-is, and not extend anything in ISSUE-279, leaving graphs alone. [scribe assist by Manu Sporny]

Manu Sporny: can these empty graphs even appear in the fromRDF algorithm?

Gregg Kellogg: it's possible that the input specifies an empty graph

Manu Sporny: +0.6

Gregg Kellogg: +1

Dave Longley: +1

Niklas Lindström: +0.75

Markus Lanthaler: +0.7

Manu Sporny: http://www.w3.org/2011/rdf-wg/track/issues/132

Manu Sporny: so we've moved away from skolemization for bnodes as predicates, dbooth has been talking about using relative IRIs

David Booth: coming into this was that there was an important use case as using bnodes as predicates which is why i recommended skolemization

David Booth: when i looked into the use cases i became more and more convinced that other approaches would be better

David Booth: the overriding motivation would be to make transitioning from JSON to JSON-LD easier, which i agree with that motivation

David Booth: i've tried to point out other ways that these use cases could be addresses, but people seemed to be attached to using bnodes here so i'd just propose that we have an option that defaults to false that, when true, will produce generalized RDF, when false it will drop bnodes as predicates

David Booth: [missed some comments]

David Booth: 1. Add an option to produce "extended RDF", which defaults to false. If the option is true, "extended RDF" will be produced, retaining triples that have blank nodes as predicates. If the option is false, standard RDF will be produced and triples with blank node properties will be discarded.

David Booth: 2. Suggest other ways to handle JSON properties that the author is not yet ready to map to stable IRIs, such as: (a) mapping them to unstable IRIs and documenting the fact that those IRIs are unstable; or (b) mapping them to "" (or such) to prevent them from appearing in the resulting RDF. Consumers that need those property values can obtain them at the JSON level (and if desired could then inject those values into the RDF without us

David Booth: ing blank node predicates).

Manu Sporny: i'd be happy with that change

Manu Sporny: i think adding the option and having it default to false will address what both sides want

Manu Sporny: and it would be good to provide suggestions for what authors can do if they want to do this kind of mapping

Gregg Kellogg: regarding unstable IRIs are you suggesting we mint a new IRI scheme for unstable IRIs?

David Booth: that's a possibility, my own view is that if people are using a documented unstable feature that's their mistake

David Booth: certainly people can document the fact that certain things are stable or unstable, and they are getting out-of-band information from them then they ought to read the documentation anyway

Manu Sporny: the only downside to minting a new scheme is making more work for the group and i can see people wanting us to create this for all RDF datasets, etc.

Manu Sporny: there would be extra work/overhead, that's the strongest argument against it

David Booth: if it were something registered it would just be a general-purpose schema that anyone could use for the purpose of unstable iris

Niklas Lindström: i agree with dbooth regarding the fact that people should pay attention to documentation, but in practice it doesn't always happen and there are cases where there have been issues with this

Gregg Kellogg: +1

Niklas Lindström: +1

Dave Longley: +1

David Booth: +1

Manu Sporny: +0.8

David I. Lehn: +1

Markus Lanthaler: +0.8

David Booth: i think there may be more push back from the web community for minting an unstable iri scheme

Manu Sporny: so in general, map bnodes predicates to an unstable IRI, one way is to use a document-relative fragment identifier

Markus Lanthaler: i think that might be confusing because you'd use those for stable IRIs too

David Booth: the point of the second suggestion was not to be prescriptive but instead to provide ideas for what devs could do to deal with this

Markus Lanthaler: can we just be silent on it? we don't recommend bnode predicates

Manu Sporny: i think it's come up so often we should mention something

David Booth: maybe just to suggest mapping to unstable IRIs and document or leave them unmapped

Gregg Kellogg: i think the people that can do that are capable of mapping to RDF without having to do unstable, etc.

Gregg Kellogg: i think this is for people who are just getting into this

Gregg Kellogg: i think we can just say that properties that aren't mapped are dropped

Manu Sporny: so we cover the case where things are unmapped that's already talked about in the spec so this may be a case where the author wants to preserve the data but not in a permanent way

David Booth: yeah, they don't want to throw away the data but they aren't yet ready to commit to a stable IRI

David Booth: that's the use case i've heard

Gregg Kellogg: aren't there owl annotations that could be used here

Niklas Lindström: .. vs: http://www.w3.org/2003/06/sw-vocab-status/ns#

Manu Sporny: i think that in this case the author doesn't want to go through the trouble of even documenting the vocabularies that they're using

Manu Sporny: they just dont' want the data to disappear but they want it to be recognized as unstable

David Booth: When mapping properties, if the author is not yet ready to commit to a stable IRI, suggest mapping the property to an unstable IRI and document the fact that the IRI is unstable.

Manu Sporny: +0.7

Gregg Kellogg: +1

Dave Longley: +0.7

Markus Lanthaler: -0.8

David Booth: +1

Manu Sporny: https://github.com/json-ld/json-ld.org/issues?milestone=none&page=1&sort=created&state=open

Manu Sporny: ok, let's go through all of the github issues and make sure we cover whatever needs covering before CR

Gregg Kellogg: if json-ld contexts could be extracted from script tags that would be a useful feature

Gregg Kellogg: it would be helpful with activity streams

Manu Sporny: i'd feel more comfortable giving advice on how to host and load contexts on the json-ld.org site because we don't know what best practice is yet

Gregg Kellogg: i agree, or it goes into some form of a best practices document that emerges

Gregg Kellogg: with regards to the other sort of profile that i'd been suggesting we might want to allow a community to sort of create other specifications to be implemented that could be folded into jsonld.next

Dave Longley: We should link to the advanced Context section from the basic context section. [scribe assist by Manu Sporny]

David I. Lehn: Yeah, I suggest that in the issue. [scribe assist by Manu Sporny]

Markus Lanthaler: +0.5

Dave Longley: +1

David I. Lehn: +1

Manu Sporny: +0.6

Gregg Kellogg: +0.5

Markus Lanthaler: https://github.com/json-ld/json-ld.org/issues?milestone=2&page=1&sort=created&state=open

Manu Sporny: We still need to discuss issues 274, 263, and apply editorial changes in 254. We'll chat next week about API issues and RDF WG issues.