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: 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: 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.
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.