JSON for Linking Data Telecon

Minutes for 2011-8-9

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0026.html
Chair
Manu Sporny
Scribe
Gregg Kellogg
Present
Dave Longley, Gregg Kellogg, Alexandre Passant, Markus Lanthaler, Manu Sporny, Ted Thibodeau Jr., Dave Lehn
Audio Log
audio.ogg
Dave Longley: I don't have voice on this end today... going to say stuff in IRC.
Dave Longley: I might not be available for the whole call either.
Note: Gregg Kellogg is scribing.

Topic: New Participants

Alexandre Passant: Hi, I'm a researcher from DERI, but I'm also the founder of Seevl - we focus on providing semantic context around music - products using structured data and disruptive Web technologies. We are starting to use JSON-LD in our product line.
Markus Lanthaler: Hi, my name is Markus Lanthaler - I'm a PhD student at the Graz University of Technology working in the field of RESTful services and Linked Data. I'm interested in JSON-LD because I needed something similar in an approach called SEREDASj - http://bit.ly/seredasj
Manu Sporny: Ok, so the additions to the Agenda are: talking about the test suite and basic spec language and/or tutorials for people.

Topic: Updates on implementations

Manu Sporny: The list of implementations growing, which is always nice to see
… Dave has done the c++, JavaScript, and PHP implementations
… we also have implementations for Erlang that are starting as well as Mike's implementation for Python
Alexandre Passant: We use standard JSON libraries to write out JSON-LD

Topic: Test Suite

Manu Sporny: have list of tests along with DB forge implementation
… compaction, expansion, framing tests
… input is valid JSON-LD, use algorithms to normalize to allow straight string comparison on output
… other things to test: convert JSON to RDF and run SPARQL queries
… In RDFa, created web service for testing with a number of input docs defined by the test suite. The test suite does a Web service call to processor service, get results, run SPARQL against the results.
… We could modify this environment to use with a JSON-LD test sute.
… problem with having an offline test suite is that every developer must write their own test harness
… RDFa harness worked pretty well - wouldn't take much to move it over since I wrote it - I know the code pretty well.
Gregg Kellogg: I'd like to see us go towards string comparisons instead of SPARQL.[scribe assist by Manu Sporny]
Dave Longley: definitely string comparisons for non-RDF, if you're handling RDF tests, perhaps SPARQL might be ok, but if we can avoid it, that would be good.
Manu Sporny: So, both of you would like us to move to straight string comparisons... sounds good.
Manu Sporny: any JSON-LD which implements normalization should output the same string.
… Other possibility, express four different types of calls: compaction, expansion, framing, and normalization.
… Make a call to the Web service, add a query parameter to tell type of output format is desired. We may need to add bits like providing context, etc too very query parameters.
… It is very useful to test each algorithm on it's own. Otherwise, don't know where implementation bugs may lie if you start off trying to test normalization (which is the most complicated of all of the algorithms).
… Modes of operations also relate 1-to-1 against the JavaScript API.
… helps with testing, and matches JS API.
Dave Longley: sounds good, but keep in mind that we might have other methods in the JSON-LD API including something that takes in triples and something that exports triples.
Markus Lanthaler: I think it would be a good idea to create a Web service to be able to test the different parts independently
Dave Longley: +1 good start
Gregg Kellogg: Exporting triples useful if BNode IDs are normalized
Manu Sporny: Seems like we have consensus on using regular string compares for JSON-LD test suite.
… four different mechanisms for output: compaction, expansion, framing, normalization.
… output of Web service calls should be the output of the API calls.
… still issues with compaction/expansion, which don't require a specific lexocographical sort order for keys in output. Can't use string comparison for those.
Dave Longley: if we define an order (lexicographically sorted keys, etc) for the outputs that might work.
Manu Sporny: may only be able to do straight string comparison on normalization tests
Dave Longley: was thinking about the same[scribe assist by Markus Lanthaler]
Manu Sporny: probably require ordering of keys and removal of white space to make tests work.
Markus Lanthaler: I think that should be a test spec, not in the main spec
Dave Longley: i don't think it needs to be spec'd out, it can just be on the test suite site
Markus Lanthaler: or just a test document
Dave Longley: +1 to what markus said.
Gregg Kellogg: +1 to markus
Manu Sporny: consensus: separate doc to describe test suite interaction.
… test harness assumes lexical ordering of keys and whitespace.
… can then test all modes of operations.

Topic: Basic / Beginners Guide to JSON-LD

Manu Sporny: 3-4 weeks ago Brian, Glenn, Kingsley had issues with JSON-LD spec.
… Kingsley was concerned about Linked Data vs. RDF conflation.
… Glenn wanted a simple way to express directed graphs.
… Brian was concerned about focus of spec. too complicated, need simpler spec.
… those three concerns resulted in the Basic JSON-LD specification. Unfortunately, I conflated all of those issues above when they are in fact, separate.
… started off as mis-guided attempt to simplify larger spec.
… we might want to create an introductory doc: "JSON-LD for Beginners"
… We could focus on only talking about the features Brian sent to list.
Manu Sporny: * All JSON objects are interpreted as resources (subjects/objects)
Manu Sporny: * @subject is the IRI for that resource (anonymous if none)
Manu Sporny: * Properties are tokens with context mappings (no IRIs and no CURIEs)
Manu Sporny: * JSON arrays are used for multiple values for a property
Manu Sporny: The current JSON-LD spec attempts to define such an easy introduction.
… Brian's approach is a good one.
Dave Longley: starting with the basics in the spec and then getting advanced works for me.
Gregg Kellogg: I think maybe starting with a basic introduction and moving toward advanced concepts.[scribe assist by Manu Sporny]
Gregg Kellogg: Unnamed nodes in the advanced section[scribe assist by Manu Sporny]
Manu Sporny: some advantage in using separate docs; We could do a tutorial: 1 per day introducing a new JSON-LD concept so that people understand JSON-LD after 5 days of reading about it for 15 minutes a day.
… latest re-write attempts to go in this direction - simple to advanced.
Dave Longley: tutorials are good as "companion" documents
Manu Sporny: line is crossed when writing tutorials in the spec which conflates audiences addressed.
… A tutorial aimed at Web developers shouldn't go in the specification aimed at JSON-LD implementers.
Manu Sporny: agree.. spec should remain a spec, tutorials should be a different thing.. we shouldn't conflate them[scribe assist by Markus Lanthaler]
Manu Sporny: a set of tutorials is better for publishers.
… We were heavy on the tutorials in RDFa and people complained that the spec was too verbose - and then went on to say "look how big the spec is - its obviously complicated"; we tried to teach too much in the RDFa spec.
… The RDFa Primer doc gives a tutorial, but it looks like a scary spec.
… HTML5 and OAuth specs don't try to give tutorial in spec... probably the best direction.
… how to implement processor, web browser, User Agent - that's stuff that only developers care about - spec language - not tutorial language.
we could have a one-page cheat-sheet
Markus Lanthaler: agree.. normally devs just read the spec when they don't find a solution in tutorials
Manu Sporny: work to simplify basic and advanced concepts in spec and move prose.
… use of spec moved to separate tutorials. 6-part series of small article.
Ted Thibodeau Jr.: We could use a wiki to write the tutorials.
Manu Sporny: hesitant about the use of a Wiki.
Ted Thibodeau Jr.: as non-coder, I don't use GitHub. Starting to have to use it, and it is a pain.
… a wiki makes sense.
Manu Sporny: other issue is history is left in database w/ wiki-based approach, and site history is not tracked.
… could set up media wiki to run off SQLite.
… my experience w/ a wiki is that it's a pain to setup, I'm usually the one that has to do it, preventing spam is difficult, and no-one ends up contributing.
… people could write word/google and other push into website.
Ted Thibodeau Jr.: There are gate-keeper issues with that approach.
… history can get lost with any tool.
… Using word-docs, everyone needs to track, version issues.
… Google docs looses history.
Manu Sporny: I'm complaining because I'm probably going to have to be the one to do it, but we probably need to implement wiki.
… other issue is fighting spam and other management headaches - the work usually falls onto the editors lap.
Ted Thibodeau Jr.: why stuff is often done in W3C space, to get admin support.
Markus Lanthaler: Are we talking about a wiki for the long term or just while writing the tutorials?
Manu Sporny: turns into editors job.
… we'll set up a wiki, and hopefully people will contribute.
Manu Sporny: agreement to set up wiki.
… wiki there for the long term, useful for more than tutorials.
Markus Lanthaler: then I kind of share your objections manu
Markus Lanthaler: I don't think that anyone will contribute after the initial phase of writing the articles.
Manu Sporny: if setting up wiki get's more participation, it's useful in spite of the admin headache.
Markus Lanthaler: let's try it
… at worst, it is a waste of time.

Topic: JSON-LD spec updates

Gregg Kellogg: Can't really comment on the stuff that Manu and Dave added.[scribe assist by Manu Sporny]
Gregg Kellogg: We removed as much "RDF" out of the doc as possible - updated the keywords - re-arranged lots of text and prose[scribe assist by Manu Sporny]
Gregg Kellogg: added support for RDF Lists via @list[scribe assist by Manu Sporny]
Gregg Kellogg: Added RDF conversion algorithms[scribe assist by Manu Sporny]
Manu Sporny: gone through and implemented various algorithms. Now "unstable" not completely experimental.
… requires 2-3 more passes to make sure we're capturing everything in the algorithms.
… working on normalization, the most difficult algorithm.
Manu Sporny: the prose goes from from beginning, to intermediate, to advanced, followed by algorithms.
… we think that is what processor writers need.
… moved other elements to the bottom: microdata, RDFa, Microformats examples in the appendix now
… not essential to spec.
… removed API section because it completely deviated from the recent changes.
… We are currently working on the following: finishing spec-language for the normalization algorithm, adding a reworked API (compact, expand, frame, normalize), may add something about web services to expose API calls.
… That should be the first feature-complete cut of the spec.
… We'll want people to do full implementations of the spec after that.
Manu Sporny: doc has changed based on input from mailing list, IRC, Twitter, and Google+.

Topic: JSON-LD Requirements

Gregg Kellogg: Moved the document forward based on comments from the mailing list[scribe assist by Manu Sporny]
Gregg Kellogg: Changed wikipedia quote to TimBL quote[scribe assist by Manu Sporny]
Gregg Kellogg: I think we've finished everything in Linked Data requirements... added a bit about structured data - I think that discussion has run it's course and this may not be necessary[scribe assist by Manu Sporny]
Gregg Kellogg: I outlined JSON-LD requirements based on these tenets.[scribe assist by Manu Sporny]
Gregg Kellogg: A JSON-LD document must be able to express a linked data graph.[scribe assist by Manu Sporny]
Manu Sporny: Should we add: JSON-LD doc must be a valid JSON document.
Markus Lanthaler: +1
… Insert this at 2.
Markus Lanthaler: why not replace 2 with it?
Markus Lanthaler: it doesn't fit the rest of the list
Markus Lanthaler: what's the advantage of having 2? I don't really get what you are trying to say with that.
Manu Sporny: We have another issue with "other literal name" - for example, we don't define what "null" means. Could say that null is undefined; has value.
Manu Sporny: Markus, the issue is syntax vs. semantics. We want to say that we fully support the JSON syntax. We also want to say that the JSON syntax is used to express Linked Data semantics. So we need two items to say that... does that help?
Markus Lanthaler: not really
Markus Lanthaler: if you are saying it has to be valid JSON then it implies that you are using JSON's constructs
Markus Lanthaler: so are you trying to say you can't use bools e.g.?
Manu Sporny: No, you can use bools... just not 'null'
Manu Sporny: Let's put this on the mailing list to discuss more
Markus Lanthaler: send out the list, not just a ref
Gregg Kellogg: I will send JSON-LD requirements to the mailing list for further discussion.
Manu Sporny: Thanks a bunch to Gregg for scribing today!
Dave Longley: thanks everyone
Dave Lehn: bye