JSON-LD Community Group Telecon

Minutes for 2012-05-15

Agenda
http://lists.w3.org/Archives/Public/public-linked-json/2012May/0005.html
Topics
  1. Finishing up the JSON-LD Syntax document
  2. ISSUE-100: Should the JSON-LD API have a "mode": "strict" flag?
  3. ISSUE-116: Introduce @extension keyword?
Resolutions
  1. JSON-LD will support a JSON-LD Processor Event mechanism that will report certain events (to be decided later) via a callback given through JSON-LD API calls.
  2. The JSON-LD Processor Event callback would be registered for every JSON-LD API call, and would provide the type of event and the data associated with the event for the callback. This mechanism would be used to report potential errors, warnings and when the processing of the document was complete.
  3. When a JSON-LD processor processes input that would result in an exception, it should instead call the JSON-LD Processor Event callback with data concerning the issue that was detected.
  4. Do not support the @extension keyword at this point in time.
Chair
Manu Sporny
Scribe
Gregg Kellogg
Present
Gregg Kellogg, Manu Sporny, Markus Lanthaler, Niklas Lindström, David I. Lehn
Audio Log
audio.ogg
Gregg Kellogg is scribing.

Topic: Finishing up the JSON-LD Syntax document

Manu Sporny: need to put some last changes in the Syntax spec before submitting to the RDF WG.
… Is it ready? Is there more cleanup necessary.
Markus Lanthaler: the last issue on the agenda may be syntax related.
… there's also the formally defined grammar.
Manu Sporny: we could create a section for the grammar and finalize after it goes to the WG.
… @type could also be discussed after it's presented to the RDF WG
… when presenting, we should know how to resolve outstanding issues.
… we should add the two open issues as issue markers in the spec.
… then we can ask for comments and push to an FPWD through RDF WG.
Niklas Lindström: what is the process once it goes into the RDF WG.
Manu Sporny: typically, they would create a task force to propose something to bring back.
… we could say we believe it's ready to be formalized and published as a rec-track doc.
… we'd try to get all of us in the RDF WG so that we could discuss it.
… almost immediately, do an FPWD, and the WG can raise issues on the spec.
… then there is a request for implementations.
… have to figure out how the CR phase should go.
… Then PR and REC. Hopefully a tighter release schedule than RDFa.
Niklas Lindström: do we want it so finished that there won't be any significant discussion?
Manu Sporny: the people in this group need to be on the same page before going in to avoid fracturing within the WG.
… if we had a fundamental disagreement about what @graph means, that could get dragged out.
… it could help focus their discussions, or it could blow things up.
… If it were not working well in the RDF WG, it could go to a different group, or that a new one could be created.
… however, it would be good to have more eyes on the work than a new group might bring.
Markus Lanthaler: if we go into RDF WG, is there a mechanism to move it someplace else?
Manu Sporny: yes, that happened with HTML+RDFa, for example.
… this is often done when things get "stuck". In the worst case, there's a spec out there that people can use.
… less likely to be an issue about JSON-LD than there was about HTML+RDFa.
Niklas Lindström: we've seen some different perspectives on how people want to use JSON-LD, but I think we've settled on the general "shape".
… There might be some issue with the overloaded meaning of @type. I probably wouldn't mind re-introducing @datatype, but we might try to make the current use more convincing.
Manu Sporny: we might fixate on this as being a big deal, but that it's not really the issue after all.
… there's no-one in the group that is disingenuous. If there's a lot of negative feedback, we might regroup.
… a couple of people in the group have read it, and most of the comments have been grammatical, not technical.
Markus Lanthaler: we would present the syntax and not the API document, right?
Manu Sporny: yes. We're not putting out the API document yet, because we want to see how people actually use it.
… this allows people to see that the syntax is solid first.
Niklas Lindström: framing is important. we should have some slack.
Gregg Kellogg: I think people may have questions about how the RDF conversion works - not having an API spec to reference could create more issues. [scribe assist by Manu Sporny]
Manu Sporny: the docs there, it's just that there might not be a normative link.
… we could say the reasons whey there is not a normative link, but continue to reference it.
… this allows us to focus on the syntax, and not get into more complex areas until it's more widely used.
Gregg Kellogg: One of my concerns is about named graphs - it seems like as they go on, they create more issues. [scribe assist by Manu Sporny]
Gregg Kellogg: If JSON-LD goes in, and there are various issues around a non-normative API - it may cause us to spin. JSON-LD might be different as it doesn't have to do with core semantics - doesn't need to be a pedantic discussion. [scribe assist by Manu Sporny]
Manu Sporny: that's why we all need to be on the same page.
… the way we address that is to describe our process for creating what's there. The core semantics can be figured out later, by a different group of experts.
… up until now, they haven't had a concrete need for it to be done. JSON-LD puts some pressure on that takes a stand.
… we can then see if this allows consensus to form.
Manu Sporny: we're splitting hairs on implementation details in the API; we're in good agreement about the core principles.
Markus Lanthaler: I t think we have general agreement; we're down to possible changes in expanded form.
Niklas Lindström: possible reservation about issue #120, which could be a hint that overloading @type is problematic
… for me, datatype has some meaning separate from type.
David I. Lehn: should we put more work in to a primer?
Manu Sporny: ideally, we'd have a primer, which is a quick read.
… the beginning of the syntax doc is something like a primer, though.
David I. Lehn: my approach was that of the novice JSON programmer, who wants to know how to turn is date into Linked data.
Manu Sporny: we could put up a wiki, but then it doesn't get edited.
… everyone here has commit rights to the repo, so we should just put up a page.
Gregg Kellogg: We may just want a portion of the website that has examples - just examples that they can browse through and see things. [scribe assist by Manu Sporny]
Niklas Lindström: I had some ideas, that are more like stories. One would be a generalized approach for legal information.
Manu Sporny: let's create an examples page that could list a bunch of examples, and then clicking on it could reach out to JSON-LD.
Manu Sporny: plan of action to make one more pass through syntax doc and tell the RDF WG we're ready to have it discussed there.
Manu Sporny: we would all transfer into the RDF WG, and the community group would pretty much go away.
… Work would proceed within the RDF WG.
… if we're successful, we'll be the first CG to get a rec-track spec out.
David I. Lehn: (we need a logo and t-shirts)
Markus Lanthaler: :-)

Topic: ISSUE-100: Should the JSON-LD API have a "mode": "strict" flag?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/100
Manu Sporny: first question, have a strict more or validate option in the API.
… second, if there is a mode, should there be just strict and lax or strict, match and lax?
… strict raises errors on any errors.
… match would just drop problematic data
… lax would try to change things based on authors intent.
… a fourth option would be a lint option.
Markus Lanthaler: don't really see the need for these options. JSON-LD isn't intended for human use, so there may not be anyone to "see" that there's an issue. If we don't through an exception, it could just be lost.
… we had said that JSON-LD should be as forgiving as possible. Note sure what these modes do in algorithmic terms.
Manu Sporny: base concern is that we started out by saying that it should be forgiving; this should be the default probably.
… in general, we want it to be forgiving; but there are cases where having a forgiving process is not ideal; it could create more complex code or allow bad data to be introduced.
… one of the reasons developers prefer JSON to XML is because it's readable.
… key concerns: we'd burden a subset of developers. Some want exceptions thrown when anything unusual happens. Others don't really care about error cases.
Markus Lanthaler: if we're doing fromRDF and we get something unusual (say "five"^^xsd:integer)
Niklas Lindström: .. <> dc:creator "Some Body" vs. <> dc:creator [ foaf:name "Some Body" ]
Gregg Kellogg: if I was importing RDF data, and I had data that didn't match what I expected, then throwing an exception in that case might be useful. [scribe assist by Manu Sporny]
Gregg Kellogg: I might switch from "strict" to "lax" when I go from development to production mode. [scribe assist by Manu Sporny]
Niklas Lindström: Jena does seem to do some checking, and I've used that to find JSON errors before.
… I would really make use of all three modes.
Manu Sporny: in HTML5 we learned that people use bad formats, but people expect it to work.
Niklas Lindström: s/find JSON errors/find RDF datatype errors/
… people prefer something that recover when they can. This says that strict mode shouldn't be the default.
… there are a subset of people that care about things that are wrong.
Markus Lanthaler: we changed conversion of native types to just fromRDF, so it's not as much of an issue.
Niklas Lindström: .. <> dc:created "today" => "created": {"@id": "dc:created", "@type": "xsd:date"} => different effects depending on mode
Gregg Kellogg: What the developer needs is potentially something that we can't consider in this group - such as linting - that should be done outside of this group. Maybe we want to be a bit softer - "do stuff w/o any normative language on what should be done". That gives implementers a hook to use that as a basis for doing their own linters or pedantic checkers. [scribe assist by Manu Sporny]
Markus Lanthaler: Niklas, this term would never be choosen in compaction because the type doesn't match
… or are you talking about fromRDF()?
Gregg Kellogg: We want to give developers a hook to make implementing this easier. [scribe assist by Manu Sporny]
Markus Lanthaler: we should come up with the list and decide upon that.
Markus Lanthaler: ah, right. With this rule I think my case for compaction is safe. in fromRDF, I think if no term is found, it's ok if the full iri fordc:created is used with an expanded literal form. [scribe assist by Niklas Lindström]
Gregg Kellogg: Strict mode flag when applied to anything that uses expansion, would warn about ignored data - either properties or data. Strict mode flag in compaction would do the expansion and report on problems applying the context to the data. In framing, it would warn you about syntax issues in the frame in addition to issues inexpansion/compaction. [scribe assist by Manu Sporny]
Gregg Kellogg: Data type checking comes in when you go from RDF into JSON-LD - and depends on how you do the translation. If booleans/doubles need to be converted into native types. If they ask that "five" be transformed intoxsd:integer, but they cannot be translated into native form. [scribe assist by Manu Sporny]
Markus Lanthaler: I see the use case in from RDF
Manu Sporny: What happens if you do this - "@id": 5 [scribe assist by Manu Sporny]
… this could warn about native datatypes which don't match the lexical representation. I don't see the value for compaction, expansion, framing.
Manu Sporny: It would be very bad for us to error out on simple issues like "@id": 5 - that's what XHTML1 did and it didn't solve any issues. [scribe assist by Manu Sporny]
Gregg Kellogg: RDFa does this via processor graphs - don't know if we want to introduce this concept to JSON-LD. [scribe assist by Manu Sporny]
Gregg Kellogg: It's pretty clear to me that we need a flag. There are some things where we found that we need it. Processors should do "best-effort" when producing JSON-LD. Maybe there is a callback instead of an exception mechanism. [scribe assist by Manu Sporny]
Manu Sporny: I like that - instead of a flag, the APIs take an extra callback - "onError()"? [scribe assist by Manu Sporny]
Gregg Kellogg: You could have a single closure associated with the data - and the program would halt if the callback responds back with a "false" - which means "stop processing". [scribe assist by Manu Sporny]
Gregg Kellogg: for example, .expand() has a callback... [scribe assist by Manu Sporny]
Gregg Kellogg: We could use the JSONLD callback to report the issue - the 'type' of the error, and a 'message', and based on the class of the error - there is some other data. [scribe assist by Manu Sporny]
Markus Lanthaler: Yes, but we should have the list. [scribe assist by Manu Sporny]
Manu Sporny: Yes, we should - but the fundamental question here is - do we have mode strict/lax mode? or do we have JSON-LD processing events? I prefer JSON-LD processing events. [scribe assist by Manu Sporny]
PROPOSAL: JSON-LD will support a JSON-LD Processor Event mechanism that will report certain events (to be decided later) via a callback given through JSON-LD API calls.
Gregg Kellogg: +1
Manu Sporny: +1 (In general)
Markus Lanthaler: +1 (in general as well)
Niklas Lindström: +1 (with details regarding error handling filled in later on)
David I. Lehn: +0!
RESOLUTION: JSON-LD will support a JSON-LD Processor Event mechanism that will report certain events (to be decided later) via a callback given through JSON-LD API calls.
Manu Sporny: Discussion about whether or not we should re-use 'callback' in the JSON-LD API.
Markus Lanthaler: http://www.w3.org/TR/websockets/#the-websocket-interface
Gregg Kellogg: In a perfect world - we might split these out into different methods - maybe... but I don't write code like that. The code paths become quite difficult in this case... you end up having processing separated "spatially" throughout the document. [scribe assist by Manu Sporny]
Manu Sporny: this often makes code more complex, as code is scattered across the page. This argues for a single callback. You don't want to overwhelm developers with options.
… this callback is called whenever a processing event happens. If you don't want to stop with errors, always return true.
… with a JSON-LD processor, you tell it to do something, and give it a callback which is used whenever there is some "event", including the end of processing.
… if you need to break it out, the developer does that inline. This give power to the developer.
Niklas Lindström: getting an event with type and message is an easy way to start. If we see that adding multiple callbacks reduces complexity, we can add later.
Manu Sporny: http://www.w3.org/TR/websockets/#event-definitions
Manu Sporny: the Event Definitions from web sockets looks like a model we could follow.
… we could give options to developers on how they want these to resolve.
… for example, we could allow them to handle datatype transforms.
PROPOSAL: The JSON-LD Processor Event callback would be registered for every JSON-LD API call, and would provide the type of event and the data associated with the event for the callback. This mechanism would be used to report potential errors, warnings and when the processing of the document was complete.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1
David I. Lehn: +0 (really need some implementations to valididate all these ideas)
RESOLUTION: The JSON-LD Processor Event callback would be registered for every JSON-LD API call, and would provide the type of event and the data associated with the event for the callback. This mechanism would be used to report potential errors, warnings and when the processing of the document was complete.
Manu Sporny: we could let the developer decide how to detail how to deal with bad data.
Gregg Kellogg: The corollary here is that whenever we say that the processor should raise an exception - we call the callback. [scribe assist by Manu Sporny]
PROPOSAL: When a JSON-LD processor processes input that would result in an exception, it should instead call the JSON-LD Processor Event callback with data concerning the issue that was detected.
Gregg Kellogg: +1
Manu Sporny: +1
Niklas Lindström: +1
Markus Lanthaler: +1 for browser implementations
David I. Lehn: +0
RESOLUTION: When a JSON-LD processor processes input that would result in an exception, it should instead call the JSON-LD Processor Event callback with data concerning the issue that was detected.

Topic: ISSUE-116: Introduce @extension keyword?

Manu Sporny: https://github.com/json-ld/json-ld.org/issues/116
Manu Sporny: Does anybody think we need to do this? [scribe assist by Manu Sporny]
Markus Lanthaler: Not I. [scribe assist by Manu Sporny]
Gregg Kellogg: We would just ignore @extension now, so they could do that... we'd just ignore it. [scribe assist by Manu Sporny]
David I. Lehn: Validation is an interesting use case - we don't do that now... [scribe assist by Manu Sporny]
David I. Lehn: It's important to think about how validation could be integrated into JSON-LD. [scribe assist by Manu Sporny]
Markus Lanthaler: Well, it would be ignored. [scribe assist by Manu Sporny]
David I. Lehn: we need to iterate on the JSON validator; it's not "easy".
… If you had a generic extension mechanism, it would at least allow people to experiment.
… there are probably better ways to do validation than we do now; perhaps operating on triples.
David I. Lehn: I don't think our (Digital Bazaar's) JSON-LD validator is easy... we need to iterate more before proposing something. I dont' think we want to force any particular validation mechanism on anyone. There is probably a better way to do validation than the way we're doing - more Semantic Webby operating on triples vs. the tree approach we're currently using. [scribe assist by Manu Sporny]
Niklas Lindström: I've recently used SPARQL 1.1 and 'schemarama" which helps.
Markus Lanthaler: are we not resolving this issue?
Manu Sporny: actually, yeah let's do that.
David I. Lehn: look at your clock :)
Markus Lanthaler: takes 2 minutes if we agree :-)
PROPOSAL: Do not support the @extension keyword at this point in time.
Manu Sporny: +1
Markus Lanthaler: +1
Niklas Lindström: +1
David I. Lehn: +1 but we should look at the use case for this and figure out how to provide the needed hooks
Gregg Kellogg: +1
David I. Lehn: @extension may not be right, but we probably need something for this
RESOLUTION: Do not support the @extension keyword at this point in time.
David I. Lehn: hmm. i'm unsure about this. i think maybe the @extension request is not even the right issue to be raising. it would be better written as how to support such things as validation and schemas