Niklas Lindström: regarding framing we might take into account as well ISSUE 140 (objectify) as well
Manu Sporny: Any updates to the agenda? I have two things - would like to hear from Gregg about NoSQL + JSON-LD discussion, and I had a long discussion w/ Richard Cyganiak that was good. [scribe assist by Manu Sporny]
... probably we should start off with framing and look at that as an alternative to it
Topic: Talk about JSON-LD at NoSQL conference
Gregg Kellogg: the audience was a bit unusual as NoSQL is just not *a* thing.. it's a lot of things
... the tendency in Mongo is to use small docs however this can lead into severe performance issues
... where JSON-LD really has an advantage there is that it supports named graphs
... you can include all data collected from a source into one document in Mongo
... another interesting thing is that there were several talks about JSONiq
... which is basically XPath for JSON
... I didn't had a look at it yet.. but the basic form to use it would be flattened graphs
... a query should be something we should be able to tackle (generically)
Manu Sporny: Yes, framing was intended to do some querying
... any question regarding your talk at the conference
... how do you feel about the approach you choose this time? Was it better than last time?
Gregg Kellogg: I spent very little time on the API
... I probably should have had another slide on the API calls, describing them on a high-level
... I think this approach worked pretty well.
... there was a different group. I think the SemTech people understand the issues more to get confused :-)
Topic: Discussion on RDF Concepts terminology
Manu Sporny: I talked to Richard off-line yesterday
... Richard felt that we need to say a bit more how JSON-LD relates to RDF
... but we don't need to do this at the beginning
... he's the one to keep the terminology accross all "RDF" in sync
Niklas Lindström: +1 for Richard's contribution
François Daoust: +1 as well
Gregg Kellogg: +1
... Richard will try to write that section
Markus Lanthaler: +1
... he also proposed to re-write the introduction in terms that Web developers understand, i.e., JSON terminology
... e.g. JSON folks are more used to talk about objects than about nodes
... he also felt pretty strongly about the JSON-LD model
... he's not concerned about the people reading the model
... it's more about people trying to create interoperable specs
... we should also state clearly what JSON-LD adds to plain old JSON
... I have an idea how the introduction should look like but would like to talk about this first
Gregg Kellogg: Richard also mentioned to remove the whole Linked Data definition from the spec
Manu Sporny: Yes, that's another point
Niklas Lindström: the thing the draw me to RDF in general is that there is a clear intent on the conceptual level that you describe things on themselves
... you have not raw data as in a table but you have a clear link to the domain model
Manu Sporny: OK, I'll give it a try
Gregg Kellogg: I would be -1 for renaming node definition/reference to object definition/reference
Manu Sporny: This brings us to the last point
... Richard was concernced about specifying what is linked data and what isn't linked data
... this might be problematic as the web might change in the future
... so we should take the normative linked data definition out and just define the JSON-LD's data model instead
Gregg Kellogg: I agree that moving it away from defining Linked Data is a good idea
... it's not really the job of a syntax/API spec to define something that broad
Niklas Lindström: I'm wondering what we are aiming at.. I mean we wanna make it compatible to RDF, right?
Manu Sporny: Yes, and the answer is the RDF appendix Richard will be working on
... but we can't say JSON-LD is a 1:1 serialization of RDF
... the last resolution we made was "Attempt to add other @container options, such as "@container": "@language" to support Wikidata's language-map use case."
... I don't know what the other's position is
... my position clearly changed.. I was against it at the beginning but after working on integrating some systems into JSON-LD I think I would be +1 on supporting this now
Gregg Kellogg: I'm a bit more worried about using it deeply in a document
... I would instead see it more reasonable at the document's top-level
... which means it would need to work differently from other @containers
... otherwise it's difficult to understand the data by just looking at a document
... so summarized I would be +1 for having it at the top-level
Niklas Lindström: I generally agree with Gregg
... it would be interesting some examples of the work you talked about before Manu
Manu Sporny: I will try to add some
Niklas Lindström: I think generally this is very useful for expansion (less so for compaction)
... just like language maps it distorts the data shape
... but the ID is such a fundamental concept that makes it problematic
Manu Sporny: I tend to agree
... if people start using all the available ways to express data it's very difficult to read documents
Gregg Kellogg: there are a lot of practical reasons to support that at the top-level
... e.g. node maps, graphify etc.
... otherwise we use a data structure internally and there's no way to express that as a document in general
Manu Sporny: I'm a bit worried about just supporting it at the top-level
... not even the example in the issue is at the top-level
... I'm worrying that adding just that doesn't address the issue
... my preference right now is to do just nothing
Niklas Lindström: do we already support this for graphs?
Markus Lanthaler: no
Niklas Lindström: we already support similar things so it wouldn't be too far off the path
Markus Lanthaler: What's the difference between this and language maps? [scribe assist by Manu Sporny]
Gregg Kellogg: It's fairly easy to understand what a language map is doing just by looking at it... that's not necessarily true for @id maps. [scribe assist by Manu Sporny]
Manu Sporny: Does anyone feels strongly about addressing this in JSON-LD 1.0?
Niklas Lindström: Just as Markus just said it is often a very efficient way to access data
... if someone has a bunch of resources that are tightly bound together you either frame the data using one root node or you keep the data in something like a node map
... doing graphify would make this probably make unnecessary as everything would be linked
PROPOSAL: Do not support id-maps via 'container'; '@id' in JSON-LD 1.0.
Manu Sporny: +1
Gregg Kellogg: +1
François Daoust: +1
Niklas Lindström: +-0
Markus Lanthaler: +0
RESOLUTION: Do not support id-maps via 'container'; '@id' in JSON-LD 1.0.
Markus Lanthaler: I already checked the text, it's been changed and I think it addresses Gavin's issue. So, I closed the issue. [scribe assist by Manu Sporny]
Manu Sporny: I'll ping Gavin to make sure he's okay with the change. [scribe assist by Manu Sporny]
Topic: ISSUE-155: JSON-LD introduction via data model
Manu Sporny: This what we discussed at the beginning of the call
... I think we handled that already in the beginning of the call and I think we have agreement on this
Manu Sporny: In general, the introduction should be re-written to do the following things, in this order:
Manu Sporny: 1. Basic Introduction to what JSON-LD is about.
Manu Sporny: 2. Basic introduction to the JSON model and what JSON-LD enables over the regular JSON model. Try to use JSON model terminology as much as possible at this stage.
Manu Sporny: 3. An introduction to the JSON-LD data model (this is currently the Linked Data section, but it may be renamed to avoid conflict in the RDF WG)
PROPOSAL: Rewrite the introductory portions of the JSON-LD document to explain JSON-LD in JSON terms first, then describe the advantages of JSON-LD, then rework the Linked Data section as the JSON-LD data model section.
Gregg Kellogg: +1
Manu Sporny: +1
François Daoust: +1
Niklas Lindström: +1
Markus Lanthaler: +1
RESOLUTION: Rewrite the introductory portions of the JSON-LD document to explain JSON-LD in JSON terms first, then describe the advantages of JSON-LD, then rework the Linked Data section as the JSON-LD data model section.
Topic: ISSUE-109: Add flatten() method to JSON-LD API
Gregg Kellogg: we might wanna have a flag to the call to just return the node map instead
Markus Lanthaler: I wouldn't like to just have a flag.. I would prefer having two methods instead
Gregg Kellogg: Is the result of flatten() compacted?
Markus Lanthaler: no
Gregg Kellogg: I rely on that in my graphify() and it would be also useful in other scenarios such as using it with backbone
... I think the question is whether we reduce the number of entry points or create API calls that depend on each other
Manu Sporny: I'm worried that adding all that atomic stuff makes it more difficult for people to learn the API
Niklas Lindström: first my graphify/connect doesn't flatten first.. it just traverses entire documents
... the other thing is whether we need a flatten() method or whether we should have a flag to expand() to flatten a document
... or compact()
Gregg Kellogg: I like that idea
Markus Lanthaler: You could use an empty frame, and that would flatten it. [scribe assist by Manu Sporny]
Manu Sporny: I think we all agree that some form of flatten should go into the spec
Manu Sporny: Ok, so four options 1) Add a 'compact' flag to .expand() and .compact(), 2) Add a .flatten() method, 3) Add a .flattenToMap() call, and 4) .frame(obj, {}) would flatten. [scribe assist by Manu Sporny]
Manu Sporny: 1) +1, 2) +0.5, 3) +0 - separate issue, 4) -1 - i don't think we're going to support .frame()
Niklas Lindström: 1) +1(but the flag should be called 'flatten' or perhaps perferably 'merged'?), 2) -1, 3) +0, 4) -1
Gregg Kellogg: 1) +1, 2) +0.5, 3) +0.5, 4) -1
François Daoust: I'm a bit confused by the different options - I'm concerned that where a method can return something that isn't JSON-LD in the end. [scribe assist by Manu Sporny]
Gregg Kellogg: One thing flatten() allows you to do is to pass a graph name and it just returns you the contents of that graph
... this should be supported as well as something which allows you to get back as well the graph definitions itself
François Daoust: I'm concerned that depending on a flag, you get something different out of the API. [scribe assist by Manu Sporny]
François Daoust: It seems like we should be able to get JSON-LD out of .compact, .expand, etc. I understand that we don't do this for toRDF, and that's fine. [scribe assist by Manu Sporny]
Gregg Kellogg: You are right, developers want indexed documents. If I just get back a flattened document I would have to go and redo the step of creating an indexed structure
Manu Sporny: I think we need to seperate these two issues: flattening and id-maps
... let's just try to decide what to do with flattening
Niklas Lindström: I agree.. and looking at the votes we probably end up adding a flag to compact/expand
... one detail: "merged" might be a better term then "flatten"
Gregg Kellogg: Is kind of doing both
PROPOSAL: Support a 'flatten' option to .expand() and .compact(). The value of the option will be the graph to flatten and return. The default value will be false, to ensure that that the JSON-LD input document is not flattened.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
François Daoust: +1
Markus Lanthaler: +1
RESOLUTION: Support a 'flatten' option to .expand() and .compact(). The value of the option will be the graph to flatten and return. The default value will be false, to ensure that that the JSON-LD input document is not flattened.
Niklas Lindström: Just wanted to tell you that in my implementation I also support @type maps
Manu Sporny: I think this shows that we need some sort of .index() API method. Then we could have id-maps, type-maps, property-maps, etc. It would be the general solution that we've been looking for.
Topic: Determine if .frame() should be in JSON-LD 1.0