JSON-LD Telecon Minutes for 2013-05-28

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

http://json-ld.org/minutes/2013-05-28/

Full text of the discussion follows including a link to the audio
transcript:

--------------------
JSON-LD Community Group Telecon Minutes for 2013-05-28

Agenda:
   http://lists.w3.org/Archives/Public/public-linked-json/2013May/0086.html
Topics:
   1. RDF-ISSUE-130: Properly referencing the DOM Futures spec
   2. Discussion with Google about JSON-LD usage
Action Items:
   1. Manu to summarize rationale for proposed Gmail/JSON-LD
      changes and send it to Dan Brickley and the rest of the Google
      teams using JSON-LD.
Chair:
   Manu Sporny
Scribe:
   Gregg Kellogg
Present:
   Manu Sporny, Radu Marian, Gregg Kellogg, Sandro Hawke,
   Dan Brickley, Dave Longley, Paul Kuykendall
Audio:
   http://json-ld.org/minutes/2013-05-28/audio.ogg

Dan Brickley: (re: Google's use of JSON-LD Agenda item) I can
   join, but not right now, that'd be ideal. Sorry, this caught me
   unawares - in catchup mode after getting sick.
Manu Sporny: Dan, yes, please join when you can, we'll go along
   w/ the rest of the agenda in the meantime.
Radu Marian:  I'm just listening in today. I asked a question via
   the mailing list - got a half-answer, looking forward to getting
   the rest of my answer eventually. I know you folks are busy.
   [scribe assist by Manu Sporny]
Gregg Kellogg is scribing.

Topic: RDF-ISSUE-130: Properly referencing the DOM Futures spec

Manu Sporny: https://www.w3.org/2011/rdf-wg/track/issues/130
Manu Sporny:  Question is, how to properly reference DOM spec in
   the way that provides the most stability to the JSON-LD API spec?
   … It's not illegal from W3C process to reference an external
   document that's being developed, but we should try to be sure
   that it is as stable as possible.
   … Concern that DOM futures will change in next 1-2 years and
   we have to make it clear that the features we're using do not
   plan to change.
Sandro Hawke:  The heart is to be sure our spec is clear what it
   means if futures changes. Hopefully it won't, but if it does, we
   need to be clear if we change with it as well, or not.
   … Or we say that it is frozen as we understand it now.
Manu Sporny:  I think we are telling implementors that we will
   track changes to the referenced spec.
   … We don't want to fork the spec. editors of both
   specifications do not want to see a fork. This always leaves an
   "out of left field" change in the future, and we'll need to
   discuss that if it happens, but right now, we don't believe there
   will be such a change.
   … If there is such a change, the JSON-LD group should do their
   best to align JSON-LD with that direction.
Sandro Hawke:  what you're talking about is not a W3C
   recommendation; it's not the way that any other recs have changed
   in the past.
Manu Sporny:  except for the entire set of HTML specs.
Sandro Hawke:  a particular spec cannot change based on what
   someone else does in the future. Once you write a conforming
   piece of code, it must always be conforming in the future.
   … Pretty odd to say that a conforming implementation may no
   longer be conformant.
Manu Sporny:  there are two discussions, what implementors will
   do in the future, and what constitutes a convofmring
   implementation.
   … If you're conformant with JSON-LD 1.0 spec, implementors can
   always count on being conformat with that.
Sandro Hawke:  you can't call it a test suite and not have it use
   a future.
Manu Sporny:  what's in the API is the future object, what that
   object exposes is not part of the API.
Sandro Hawke:  I don't think that's wise, but you'll need to
   convince the director.
Manu Sporny:  we can also say what is the worst thing that could
   happen if some DOM API mechanism changes? In that case,
   implementors could provide a patch to support both old and new
   mechanisms.
Sandro Hawke:  in practice, implementors would need to provide
   both old and new versions.
Manu Sporny:  those are known unknowns. We highly doubt they're
   going to make such changes.
Sandro Hawke:  it doesn't matter what we think, but what they
   think. When will it be frozen?
Manu Sporny:  we have a statement from the DOM group, but it's
   the standard WHATWG line: it's implementable now and will be
   harder to change once there are enough implementations in the
   wild. They'll never say it's frozen.
Sandro Hawke:  we need to put this in front of the director and
   get a ruling on this.
   … Normally, the W3C doesn't put implementors in that position,
   but the whole WHATWG thing is a changing position.
Manu Sporny:  Is this enough to address your issue so we can take
   it to the director?
Sandro Hawke:  normally, this is done at CR transition.
   … We could let this wait until that transition meeting.
Manu Sporny:  Is there anything more we can discuss on this now,
   or just put out the line of argumentation to the director.

Topic: Discussion with Google about JSON-LD usage

Manu Sporny:  Dan, can you give a bit of a background?
Dan Brickley:  I'll talk about how we ended up with JSON-LD
   instead of RDFa.
   … There are many ways of putting SD in HTML, and tried
   microdata, but developers were confused with HTML markup (MD or
   RDFa).
   … An engineer tried a flatter implementation in JSON, and it
   turned out to be very close to JSON-LD.
   … The context header was scaring some of the guys, but we've
   been working through that.
   … The main difference now seems to be the use of schema.org
   instead of http://schema.org.
Manu Sporny:  that's one issue, the other concern is that Google
   isn't providing a JSON-LD context file at http://schema.org. We
   have a GSoC student who may help with this.
   … We'd just like to understand Google's position on these
   things.
Dan Brickley:  Google's not the only relevant party. If it was
   just Google, we could just stick up a JSON-LD context file, but
   this affects other parnters.
   … Microsoft had an O-Data implementation, and were concerned
   that it would shut down discussions of other possible directions.
   … I think it should be straightforward to publish one, but
   there are some hosting issues that are currently complicating
   this. It's on my todo list.
Gregg Kellogg:  It would be nice to have the JSON-LD context file
   generated automatically. [scribe assist by Manu Sporny]
Gregg Kellogg:  You want to make sure to setup types correctly
   (numbers, dates, URLs, etc.) [scribe assist by Manu Sporny]
Gregg Kellogg:  You will also want multiple values being in a
   list - for example, MusicTracks - makes sense that when you're
   listing tracks, they are ordered. Breadcrumbs are another place
   where this might be important. We made some arbitrary decisions
   when we did the Microdata to RDF translation. [scribe assist by
   Manu Sporny]
Gregg Kellogg:  I don't know if you maintain any information like
   that in the schema, it would be useful if you did. [scribe assist
   by Manu Sporny]
Gregg Kellogg:  Datetime might be an issue, you're more flexible
   with dates / times. [scribe assist by Manu Sporny]
Dan Brickley:  There is a part of this where we think that any
   property in schema.org might have really bad data - we find a way
   to deal with those cases. [scribe assist by Manu Sporny]
Dan Brickley:  there's a level at which schema.org expects to see
   a certain type of property, and we find a way to figure out what
   it should be.
   … I don't believe Google has any plans to dynamically fetch
   and parse such a context. As far as dealing with a JSON-LD
   payload, the engineers have done a good job.
Manu Sporny:  I want to make it clear that you don't really need
   to. Just because you publish a context, doesn't mean that you
   need to dynamically read it.
   … This is done in the Web Payments schema; you just want to be
   sure they're no conflict in how things are parsed.
   … We should probably try to be minimal in what is specified
   right now. For example, for right now it could assume strings for
   everything, and later on start narrowing it down to ids, dates
   and so forth.
Dan Brickley:  can the context be agnostic about the values for a
   given property.
Gregg Kellogg:  you can always be unambiguous in the data by
   using expanded values.
Manu Sporny:  ideally, the group would like to at have shema.org
   say that things should be URLs or dates.
Dan Brickley:  something minimal is more likely to be agreed
   upon.
Sandro Hawke:  for right now with RDFa, is everything a string?
   How does schema.org treat things that may be URLs or strings?
Dan Brickley: http://schema.org/docs/datamodel.html has our rdfa
   schema
http://schema.org/docs/schema_org_rdfa.html
Dan Brickley:  it's pretty conventional RDFa if you use it with
   schema.org.
   … The RDFa definition of the schema.org schema is pretty
   conventional except for a few changes for ranges and domains.
Manu Sporny:  there's a data model behind schema.org that is well
   typed, but as Dan said before, they get a lot of garbage, so they
   try to interpret values based on the vocabulary.
Dan Brickley:  it's more like if you use the "actor" property
   with a string, it infers that there is an object having that
   string as it's label.
   ... The other issues is the HTTP Range-14 issue. schema.org
   doesn't worry to much about the distinction of the web page about
   a thing and the thing itself.
   … For example, links between pages are simple links without
   re-direction, or the use of fragment indirections.
Manu Sporny:  back to the two issues, do you think that the
   @context: schema.org, vs @context: http://schema.org is going to
   be a problem?
Dan Brickley:  I think it should be okay. Remember that the
   schema.org partners haven't seen what Google's announced yet.
   We've had some discussions, but Google doesn't share product
   plans with competitors.
Sandro Hawke:  sounds like you might expect the partners to push
   back and demand the use of http://
Dan Brickley:  we can see what's actually coming in from partners
   to see what's being used in the wild.
   … It was news to me that there's a relative-link
   interpretation, in which case the http:// makes a lot of sense.
Manu Sporny:  we're in LC, and based on the direction of
   schema.org, we may need to go into another LC, plus the design
   work needed.
   … It would be nice to know which direction we need to go
   fairly soon, as we come out of LC in a couple of weeks.
   … Best for the spec and the web would be to require http://.
   Sound's like you'll talk with the parties and see if that's okay.
Dan Brickley:  At google, people seemed to be skeptical.
Gregg Kellogg:  The short of the argument is this: people are
   going to use relative URIs for publishing documents on their
   site. If you use 'schema.org' - that means, relative to URL
   [scribe assist by Manu Sporny]
Sandro Hawke:  it's also that you want to have several off of a
   same context - you want to use a URL if you want to provide
   multiple contexts in a single domain.
Dave Longley:  also, people may want to use a secure context and
   use https:// - this is very important for product data, legal
   data, financial data, etc. (there are attacks if you don't serve
   vocab data from HTTPS URLs).
Sandro Hawke:  There is also an issue with needing to reference
   files - don't use just a domain name. [scribe assist by Manu
   Sporny]
Dan Brickley:  Is anyone publishing anything using relative URLs?
Manu Sporny:  I don't think many people are using relative URLs
   for contexts; most people have just used http://.
   … If people are publishing data, and using http:// is such a
   problem, you're going to see many other problems, such as image
   locations and so forth. This didn't seem like such a stretch.
   … The argument that it's difficult for developers to put
   "https://" in front of their URLs doesn't hold, as you're going
   to require it in the data anyway.
Dan Brickley:  I think that people won't read the field as a
   link, it's a piece of boilerplate.
Manu Sporny:  in which case, they'll just copy from the examples.
   … If the examples use http://schema.org, they'll just do that.
Dan Brickley:  I think if you use http://domain, you're
   re-directed to http://domain/, so it's a bit like that.
Dan Brickley: (or http clients fix that up)
Manu Sporny:  the opinion of the group is the best course of
   action is to use: https://schema.org/ for the context [scribe
   assist by Dave Longley]
Manu Sporny:  the right thing to do would be to do
   https://schema.org/, and if you don't, then you're redirected to
   get the proper context. If you use http instead of https, you'll
   be redirected to https, so that you get the proper version.
   … The core is that JSON-LD expects a proper URL for that
   value. Either schama.org puts https:// in front, of we write up
   that this is a special case.
Sandro Hawke:  You could also say there's not context, and the
   gmail application could define it.
Manu Sporny:  true, but then it's no longer interoperable.
Manu Sporny:  good time to establish best practices.
Dan Brickley:  I'm pretty sure that the product team didn't
   realize that relative URIs were possible. I'll go back and see
   what they think.
Manu Sporny:  We'll get an email out to clarify why this is
   important.

ACTION: Manu to summarize rationale for proposed Gmail/JSON-LD changes
and send it to Dan Brickley and the rest of the Google teams using JSON-LD.

   … Good to know sooner than later.
Dan Brickley:  big mistake to think of Google as a monolith.
   different groups have their own priorities, and we look to
   minimize boilerplate.
Manu Sporny:  it sounds like the context document isn't an issue,
   and the only remaining issue is making the context value an
   absolute IRI.
   … Then we have a really good story about Google adopting
   JSON-LD, which is good for the web.
   … Bottom line, we're here to help however we can.
Dan Brickley:  Just to be clear, a fetchable context will require
   some configuration changes.
Manu Sporny:  I'd like to start with something simple, rather
   than trying to do the most correct thing.
Paul Kuykendall: Yep.
Gregg Kellogg:  We could start with something like {"@vocab":
   "http://schema.org/"}
Manu Sporny:  we'll discuss lossless conversion next week.

-- 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, 28 May 2013 17:07:19 UTC