JSON-LD Telecon Minutes for 2013-08-13

Thanks to Gregg for scribing! The minutes from this week's telecon are
now available.

http://json-ld.org/minutes/2013-08-13/

A full transcript of the meeting can be found below, including a link to
the original audio:

-------------------------------------------------------------------
JSON-LD Community Group Telecon Minutes for 2013-08-13

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0024.html
Topics:
   1. JSON-LD in the News
   2. David Booth's Editorial Comments
   3. Update on GSoC from Vikash
   4. Review of JSON-LD 1.0 CR-ready specification
   5. Review JSON-LD 1.0 API CR-ready specification
   6. Implementations and Test Suite
Resolutions:
   1. Add an issue marker for @type stating that we may introduce
      a new keyword to do literal type coercion.
   2. Request that the RDF WG publish the JSON-LD 1.0 Candidate
      Recommendation on August 22nd with a CR period of 4 weeks.
   3. Request that the RDF WG publish the JSON-LD 1.0 API spec as
      a Candidate Recommendation on August 22nd with a CR period of 4
      weeks.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Gregg Kellogg, Manu Sporny, Dave Longley, David Booth,
   Markus Lanthaler, Vikash Agrawal, Niklas Lindström,
   David I. Lehn
Audio:
   http://json-ld.org/minutes/2013-08-13/audio.ogg

Gregg Kellogg is scribing.

Topic: JSON-LD in the News

Manu Sporny:  JSON-LD got good coverage at the W3C Social
   Standards Workshop
   … Announcements from IBM, and schema.org actions.
Manu Sporny: schema.org is now using JSON-LD to describe some of
   their data: http://schema.org/Action
David Booth: Lots of discussion at Social Web meetup about
   JSON-LD: http://www.w3.org/2013/socialweb/
   … schema using JSON-LD as they have found people have problems
   with microdata/RDFa
   … As a result ActivityStreams started looking at JSON-LD.
Manu Sporny: Shane Becker said JSON-LD was unnecessary:
   http://iamshane.com/articles/2013/8/8/1/json-ld-is-an-uneeded-spec
   … subsequently micro formats community took exception, saying
   it was an "unneeded specification"
   … (Doesn't look like they actually read the spec).
Manu Sporny: I countered Shane's post here:
   http://manu.sporny.org/2013/json-ld-is-the-bees-knees/
   … That was picked up and re-tweeted a bit, so I wrote a blog
   entry to debunk it
Manu Sporny: Ade Oshineye wrote this post on JSON-LD
   https://plus.google.com/+AdeOshineye/posts/8BAahV1gQUk
Dave Longley: Dan Brickley started working on some soundcloud
   markup: https://gist.github.com/danbri/6210802
Dave Longley: Link above was a response Dan Brickley was working
   on for marking up the recording info requested by Ade
   … Ade at google wrote a post liking to shane's article
   … Conversations allow an opportunity to talk more about the
   motivations of JSON-LD
Gregg Kellogg:  The whole Activity stuff wrt. Google - it was not
   well received at all, it made it seem like they were ignoring
   Activity Streams community. Guha came to defend schema.org and
   dispel myths and was not very effective at that. [scribe assist
   by Manu Sporny]
Gregg Kellogg:  schema.org wasn't viewed nicely - they were kinda
   ignoring Activity Streams. [scribe assist by Manu Sporny]
Manu Sporny:  we may want to think about distancing ourselves
   from schema.org and other initiatives; we've seen this happen
   before with RDFa.
   … our strategy has been to talk about JSON-LD use anywhere.
   … We don't want to pick sides.
Gregg Kellogg:  One of my responses on Twitter, wrt. Microformats
   people, what it does w/ vocabularies - JSON-LD is vocabulary
   agnostic, Microformats isn't. [scribe assist by Manu Sporny]
Manu Sporny:  MF is making some change about separating
   vocabulary from markup, but there is very little activity within
   that community now.
Gregg Kellogg:  There is also a fair amount of presence by the
   IndieWeb community, Tantek being the main person there... they
   showed off some cool social media tech - indieauth... effective
   way to bring many communities together. Great forum for JSON-LD.
   Nothing we really need to do to follow up. Wouldn't worry about
   any of the schema.org stuff that came up there. They're such a
   big player that people are going to take shots at them. [scribe
   assist by Manu Sporny]

Topic: David Booth's Editorial Comments

Manu Sporny:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0025.html
Manu Sporny:  dbooth had sent out some minor changes to the
   Syntax and API specs.
David Booth:  just editorial changes to smooth out some language.
   … Text says it's a "generalized RDF dataset", but by default,
   it's standard. It also start talking about extensions before
   saying that there are extensions.
Manu Sporny:  gkellogg and I reviewed the spec and could
   integrate it.
Markus Lanthaler:  is it true that it serializes a standard
   dataset? It does allow you to put in blank nodes.
Gregg Kellogg:  It's not syntactically invalid to use blank nodes
   in predicate positions like it is in TURTLE, so it can be
   serialized, but it does not result in those blank nodes being
   emitted when you turn it into RDF. [scribe assist by Manu Sporny]
David Booth:  if the spec only constrains the end-result, then
   the end-result is standard RDF unless the option is specified.
Manu Sporny:  I can see it both ways; I don't think the proposed
   change will make a big difference.
Markus Lanthaler:  the description is somehow incompatible with
   the data model described in the spec.
Manu Sporny:  I think dbooth's approach is to talk about
   serialization, and that is data model, so we're going to have
   differences.
Markus Lanthaler:  the only place blank nodes are dropped is if
   you emit RDF.
Manu Sporny:  is this paragraph about JSON or RDF?
Dave Longley:  deserializing to an abstract syntax is the wrong
   term.
David Booth:  maybe we can move "optionally" before "serialize".
Manu Sporny:  let me look into it more and try to tweak the
   wording.
   … We'll try to change the text to address both dbooth's and
   markus' objections.

Topic: Update on GSoC from Vikash

Manu Sporny:
   http://lists.w3.org/Archives/Public/public-linked-json/2013Aug/0026.html
Vikash Agrawal:  I shared an update this week. Markus had some
   issues within the schema, as it did not include all classes and
   properties in schema.
Markus Lanthaler: bye dbooth
   … using @vocab of http://schema.org/ means that specifying
   other vocabulary terms is not vital.
   … I've moved on to the LinkedIn application.
   … A question: I get JSON from LinkedIn, should I display that
   or a modified version?
   … This could be the last coding project for the summer, then I
   could go on to documentation.
Manu Sporny:  regarding the schema.org context, markus said it's
   not complete, but we had decided to just focus on the properties
   needed for specific classes.
   … We'll need to eventually replace that with something machine
   generated; it shouldn't be that difficult to go through the
   schema and translate it.
Manu Sporny:  perhaps a bonus project would be to do an
   algorithmic transformation of the vocabulary to JSON-LD context,
   and make it better.
Vikash Agrawal:  I would go through a python crawler to retrieve
   it?
Manu Sporny:  fetching a document from schema.org and
   transforming it into JSON-LD automatically, as the vocabulary
   will be updated over time. Having to do this manually is not a
   good long-term strategy.
Vikash Agrawal:  so, I would get it every time it updates and
   re-generate the context definition.
Manu Sporny:  don't worry about that now, we'll come back to it
   later.
Vikash Agrawal:  the creator tool is done, and there are some
   validations left to perform.
Manu Sporny:  sounds like you're going to work on the creator
   tool and LinkedIn app.
   … don't work on the schema.org context anymore, and maybe come
   back to it later.
   … The w3.org redirection is fine.
   … the creator tool is a good first pass; we need to make the
   tool more generalized, so we can plug in different types of
   things. We'd like to do Organizations and other schema types, so
   they can't be hard-coded.
   … The first pass was all that we asked for; one of the things
   you could do in the future would be to make it generic, for
   example having a JSON-LD file to describe the types and form
   elements.
Vikash Agrawal:  Do you want me to make the creator tool more
   generic? Add those options you mentioned?
Manu Sporny:  don't worry about them now, when you're done, we
   can come back to it.
   … Is LinkedIn application published anywhere?
Vikash Agrawal:  for LinkedIn, I won't be able to publish. If
   possible, you need to pull it down and test it on a local
   machine, so it can't be deployed (?)
   … what should be presented in the application?
Manu Sporny:  the ideal tool would allow you to put in a LinkedIn
   profile name, fetch the JSON, convert to JSON-LD and return it in
   a text-box.
Vikash Agrawal:  I was thinking that after signing it, user would
   see both JSON and JSON-LD, or we could just show JSON-LD with
   computations in the background.
Manu Sporny:  just show JSON-LD, but could have an "advanced" tab
   to show original JSON, but hide it by default.
Dave Longley:  isn't the idea for the JSON-LD to look just like
   the JSON you got with an @context?
Manu Sporny:  I was thinkingg it would be translated to
   schema.org markup, we would do the transformation.
Dave Longley:  it might be good to see the JSON-LD just using a
   context, and then after you've converted it to schema.org.
Manu Sporny:  my understanding of the purpose of the code is just
   to allow people to see their data as JSON-LD
Dave Longley:  why wouldn't we want it to look as much as the
   original JSON as possible?
Manu Sporny:  the data they publish is not very intuitive. The
   primary use case is schema.org, not LinkedIn.
Dave Longley:  other people might want to reused the context for
   other uses.
Manu Sporny:  that belongs in an advanced tab.
   … I was hoping that people would just copy and paste the
   JSON-LD and put it into a file on their website, or into a script
   tag in their profile page.
Vikash Agrawal:  an advanced tab would be a good way to do it.
Gregg Kellogg:  Meta comment - your audio has been very difficult
   to understand, probably because you're not using a headset and
   possibly bandwidth issues. Please try to get a headset. [scribe
   assist by Manu Sporny]
Vikash Agrawal:  I've had some problems with my data plan.
Manu Sporny:  I think the major problem is the lack of a headset.

Topic: Review of JSON-LD 1.0 CR-ready specification

Manu Sporny: http://json-ld.org/spec/latest/json-ld/
Manu Sporny:  I prepped a spec last week for CR, including
   everything but dbooth's updates
   … I think the CR spec is ready to go from an editorial
   perspective.
Dave Longley:  my comment is that people have complained about
   overloading @type, either because they haven't read it, or it
   requires some more explanation.
Markus Lanthaler:  the problem is that people aren't really
   reading the spec.
Manu Sporny:  we could mark the use of @type in the context as at
   risk and introduce @datatype in the future.
Dave Longley:  that's not the problem.
Manu Sporny:  then the issue is a reading comprehension problem.
   … they're not reading enough to know the difference. We've
   always had this issue.
Niklas Lindström:  The problem is that the overloading of @type
   isn't carried through because we treat the concept of datatypes
   as something different than RDF types.
   … Would @datatype change the distinction?
   … It might address the problem unless people start to use
   @type instead of @datatype.
   … OTOH, using @coerce in the context imply that people don't
   really think about type, but values.
   … we could use @value instead of @type in the context
Markus Lanthaler:  or allow @type to be used for data-injection,
   as people have assumed.
Manu Sporny:  round-rripping becomes problematic, because we
   wouldn't know if to remove the type later
Niklas Lindström:  that would mean that we could only do this for
   types, and not other properties.
   … I would be fine with introducing @coerce, or @value
Manu Sporny:  @coerce might have a similar problem
Dave Longley:  we might need a different keyword
Niklas Lindström:  the keyword should imply: "treat the string
   value as something other than a string"
Manu Sporny:  just put an @ sign in front of that phrase!
Niklas Lindström: .. @coercevalue
Dave Longley: @interpretAs @interpret
   … Let's put an issue marker next to this indicating that we
   might introduce a new keyword. Once people learn it, they don't
   forget it.
Niklas Lindström:  could we propose to examine the possibility of
   another keyword.
Markus Lanthaler:  what problem are we trying to solve? People
   don't know the different of types in statements or literals, this
   doesn't change that.
Manu Sporny: we could do @literalType
   … People understand this once it is explained, and will
   resolve itself
Niklas Lindström:  I think the use of @type in context does
   introduce a threshold which will never go away and will be a
   hurdle. I find it a bit strange when I look at the data. We have
   other specific keywords which send a specific signal.
   … When I see @id and @type together, you have to wonder what
   it means.
Dave Longley:  We should try to add an "explain" feature to the
   playground, which would go line by line to describe what the data
   means.

PROPOSAL: Add an issue marker for @type stating that we may
   introduce a new keyword to do literal type coercion.

Niklas Lindström: +1
Manu Sporny: +1
Dave Longley: +1
Vikash Agrawal: +1 (surely)
Gregg Kellogg:  +0.2
Markus Lanthaler: -0.9
Niklas Lindström: (.. e.g. "@type": "@id" vs. "@coerce": "@id")
Markus Lanthaler:  I don't think it will address the issue and
   just trigger more confusion.
Dave Longley: changing mine to a -1
Manu Sporny:  by not putting it in the spec, it could cost us
   another 4 weeks. By putting into the spec, it enables us to
   change.
Vikash Agrawal: Can we have @expandTo
Markus Lanthaler:  even if we add an issue marker, I think we
   would have to go back to LC
Manu Sporny:  no, that's not how the W3C process works. you're
   allowed to do this if you've used an issue marker.
Markus Lanthaler:  this looks like the API issue that put is back
   into LC
Manu Sporny:  we're not into LC anymore, so the rules are
   different. We wouldn't actually need to go back to LC.
   … The reason for this is to prevent from going from CR back to
   LC.
Niklas Lindström: .. also, recall that berjon first problem in
   the examples was "@type": "@id"..
Dave Longley:  my vote is for least-friction, whatever that might
   be
Dave Longley: +1
Dave Longley:  I'm willing to trigger more discussions if this
   will help.
Niklas Lindström:  if manu isn't correct, then I expect markus
   and dlongley to actually vote -1 to making the change, if it
   comes to that.

RESOLUTION: Add an issue marker for @type stating that we may
   introduce a new keyword to do literal type coercion.

Manu Sporny:  my assumption is that we won't make a change.
Dave Longley:  danbri was confused about @type: @id, if you're
   expecting a URL or an object or array of objects (which you can).
Gregg Kellogg:  Confusion there may be about type casting may
   work on things that are not bare strings... type casting is only
   meant to apply to strings. [scribe assist by Manu Sporny]
Markus Lanthaler:  same for @language
Dave Longley:  it could be to say "if a string is found in the
   value position, it will be used to interpret that". Highlighting
   that fact might be helpful.
   … If you look at example 3, it's misleading.
   … It should say if a string is encountered as a value, it
   should be interpreted as an IRI
Manu Sporny:  I had that in spec-text before, but it was a lot to
   swallow in the 3rd example.
   … It's going to be difficult for people to understand why
   we're being so specific.
Dave Longley:  I don't think we need to make a lot of substantial
   changes, we could just say "if the values are strings, they can
   be interpreted as IRIs.
   … We could say that in the example, and in the paragraph after
   the example.
   … it's only a couple of words.
Niklas Lindström: .. something like "This means that any string
   associated with 'image' shall be interpreted as an object with
   this string as its identifier"?
Manu Sporny:  I'm dubious that it will help, but fine in putting
   in some text.
Dave Longley:  also after example 10, we could change the "even
   though …" text a bit to "since ..."
   … text after example 3, 4 and 10
Niklas Lindström:  I'm concerned about how we say that things are
   interpreted as IRIs. We really mean that it implies there's an
   object with that identifier. People already know that a string
   can be an IRI
   … I think we're a bit in "RDF mode" in our minds, if they
   instead thought of the string as representing an object with an
   @id key.
Manu Sporny:  these are editorial changes, which can be made
   after CR. We should focus on changes that need to be done before
   CR.
Manu Sporny:  any concern about JSON-LD 1.0 spec for CR?

PROPOSAL: Request that the RDF WG publish the JSON-LD 1.0
   Candidate Recommendation on August 22nd with a CR period of 4
   weeks.

Manu Sporny: +1
Dave Longley: +1
Gregg Kellogg: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +1
Vikash Agrawal: +1

RESOLUTION: Request that the RDF WG publish the JSON-LD 1.0
   Candidate Recommendation on August 22nd with a CR period of 4
   weeks.

Topic: Review JSON-LD 1.0 API CR-ready specification

Manu Sporny: http://json-ld.org/spec/latest/json-ld-api/
Markus Lanthaler:  had a question about exit criteria, which was
   taken from another spec.
   … Also about @context, on how it can be accepted. The only
   thing that isn't support is an array of objects having @context.
   … We could support this, but it would need to change the API
   algorithms.
   … This could mean that some problems wouldn't be found.
   … You could embed a context with another context, which would
   be problematic
Manu Sporny:  is there a major use case we're missing?
Markus Lanthaler:  I really don't see a use case, just what you
   presented last week, but that can be implemented quite easily.
   … It's really about allowing some syntactic sugar which isn't
   currently allowed.
Dave Longley:  my implementation allows it, but I don't really
   care that much. Markus is right that you could do this in
   pre-processing pretty easily.
Manu Sporny:  I think it's safe to not add at this point, we can
   always come back to it in the future.
   … I have some concerns about the explanations of each section.
   Since it's the API spec, I don't think it's super critically, but
   we might want to make language more accessible during and after
   CR

PROPOSAL: Request that the RDF WG publish the JSON-LD 1.0 API
   spec as a Candidate Recommendation on August 22nd with a CR
   period of 4 weeks.

Manu Sporny: +1
Dave Longley: +1
Markus Lanthaler: +1
Vikash Agrawal: +1
Gregg Kellogg: +1
Niklas Lindström: +1
David I. Lehn: +1

RESOLUTION: Request that the RDF WG publish the JSON-LD 1.0 API
   spec as a Candidate Recommendation on August 22nd with a CR
   period of 4 weeks.

Manu Sporny:  markus and gregg, please propose to move to CR on
   the next call.

Topic: Implementations and Test Suite

Gregg Kellogg:  mine's up to date.
Markus Lanthaler:  Mine does to, except for new @context stuff.
Niklas Lindström:  the rdflib JSON-LD does for python
Dave Longley:  javascript does
Niklas Lindström: .. https://github.com/RDFLib/rdflib-jsonld
Gregg Kellogg:  the Java implementation is close to passing
Manu Sporny:  enough to get through CR
Markus Lanthaler:  Manu, are you giving the W3C web master a
   heads-up.
Markus Lanthaler:  we can timestamp the documents now.
Manu Sporny:  hopefully we'll be out of CR in another month and
   into PR

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Tuesday, 13 August 2013 16:30:00 UTC