Linked Data in JSON Telecon 2011-08-09

JSON for Linking Data Telecon

Minutes for 2011-08-09

Permalink
  http://json-ld.org/minutes/2011-08-08/
Agenda
  http://lists.w3.org/Archives/Public/public-linked-json/2011Aug/0026.html
Scribe
  Gregg Kellogg
Present
  Dave Longley, Gregg Kellogg, Alexandre Passant, Markus Lanthaler,
  Manu Sporny, Ted Thibodeau Jr., Dave Lehn

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

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: PaySwarm Developer Tools and Demo Released
http://digitalbazaar.com/2011/05/05/payswarm-sandbox/

Received on Tuesday, 9 August 2011 19:16:39 UTC