xAPI-Spec
xAPI-Spec copied to clipboard
adlnet
Extensions: JSON Schema Validation
I get the point of not allowing LRSs to reject statements based on non-recognized extensions, but it seems to me that this is akin to saying "take this stuff that is (to you) useless garbage and store it because I say so."
Requiring extensions to carry a JSON Schema would allow LRSs to determine how to utilize the information contained within and make the extension useful to any receiving LRS.
Yes, yes, I know, breaking change, 2.0.
I think the best possible implementation would involve using JSON-LD, but that's probably its own issue.
EDIT:
I retitled the issue b/c I think the JSON-LD stuff was clouding the issue... the proposal here was simply to allow LRSs to validate extensions that carried a JSON Schema (and reject broken ones) as a patch issue, with an eye toward (perhaps) requiring schemas and using JSON-LD in extensions in a future version (2.0?)
I'm interested to learn more about JSON-LD as @aaronesilvers also mentioned this recently. I did have a very quick look on wikipedia and couldn't see how it would convey enough information to be useful but i'd love to hear from somebody more knowledgable on the subject.
Would somebody be willing to do a short presentation on one of the calls?
Allowing or even encouraging (rather than requiring) extensions to make use of JSON-LD might be a something that could be done in 1.0.3 or 1.1.0. So long as JSON-LD is valid JSON I guess it's already allowed in extensions. It could also be required by particular recipes outside the spec.
@garemoko this is something that was recently adopted for the OBI 1.1 spec, I think I have some slides from one of those calls that explains how it works for Open Badges, I'll try to find them and either link or send out to the list.
I'm pretty sure the "official" stance on JSON-LD is that it has its own MIME type, but as it doesn't "break" valid JSON to the best of my knowledge, I don't think it should be an issue? I'll follow up soon. It would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps with the possibility of a MUST in 2.0.
The issue I have with JSON Schema is that JSON Schema validators are all over the place with level of support for many parts of the standard, which makes it hard to be sure one's schema is fully right. Additionally, I think JSON-LD is a much better candidate for machine-described rich JSON content. It's still a good idea to publish a JSON Schema when there are more complicated validation needs, but it doesn't make sense to require extensions be validated against schemas for acceptance.
What's more, LRSs can support JSON-LD without breaking xAPI. It would be breaking to add the JSON-LD attributes and add the mime-type (both must be done to serve JSON-LD content directly), but the JSON-LD standard allows for providing a JSON-LD context via a Link header, which is entirely allowed. All it would take is one place publishing a good JSON-LD context that everyone could then link to.
Additionally, extension authors could place a JSON-LD context directly into extensions. I don't think we need to put that in the standard yet, but I'd like to strongly encourage it.
Sincerely, Russell
On Tue, Jan 6, 2015 at 10:58 AM, Jason Lewis [email protected] wrote:
@garemoko https://github.com/garemoko this is something that was recently adopted for the OBI 1.1 spec, I think I have some slides from one of those calls that explains how it works for Open Badges, I'll try to find them and either link or send out to the list.
I'm pretty sure the "official" stance on JSON-LD is that it has its own MIME type, but as it doesn't "break" valid JSON to the best of my knowledge, I don't think it should be an issue? I'll follow up soon. It would be awesome to get it in as a MAY or SHOULD in 1.0.3 or 1.1.0, perhaps with the possibility of a MUST in 2.0.
— Reply to this email directly or view it on GitHub https://github.com/adlnet/xAPI-Spec/issues/577#issuecomment-68913688.
@fugu13 @garemoko Here's Nate's presentation for using JSON-LD in OBI extensions, as promised:
Open Badges Standard Extension Proposal
I agree that JSON Schema can be overkill in some places, but I think the OBI folks came up with a good balance. It's not isometrically applicable to xAPI, but I think LD could not only clear up extensions, but solve some problems in other areas. And again, since it's valid JSON, it wouldn't break compatibility, earlier versions could safely ignore it.
I'd like to +1 any exploration/move towards JSON-LD. It plays nicely with RDF. It works really well with OWL (web ontology language... let's not get into why it's not WOL instead of OWL), which if we're serious about registries, taxonomies, ontologies... well, you get the picture there. It enables more potential for what little it may potentially add.
-a-
#mobile
Aaron E. Silvers | MakingBetter http://makingbetter.us/ 857.34.BEARD | @aaronesilvers http://twitter.com/aaronesilvers
Let’s meet! Pick a time https://doodle.com/makingbetter.
On Tue, Jan 6, 2015 at 3:03 PM, Jason Lewis [email protected] wrote:
@fugu13 https://github.com/fugu13 @garemoko https://github.com/garemoko Here's Nate's presentation for using JSON-LD in OBI extensions, as promised:
Open Badges Standard Extension Proposal https://docs.google.com/presentation/d/1dWMU2gdnfjBPRJTCcCDOJrs0xSgCwNc-IOUdjq9gRmw/edit?usp=sharing
I agree that JSON Schema can be overkill in some places, but I think the OBI folks came up with a good balance. It's not isometrically applicable to xAPI, but I think LD could not only clear up extensions, but solve some problems in other areas. And again, since it's valid JSON, it wouldn't break compatibility, earlier versions could safely ignore it.
— Reply to this email directly or view it on GitHub https://github.com/adlnet/xAPI-Spec/issues/577#issuecomment-68924481.
+1 for JSON-LD, not something I've read a lot of, but looks like a solution to things that have been bugging me for a long time with JSON.
@andyjohnson please also label this at patch and minor as I think there may be things we can do at those stages too.
@garemoko @andyjohnson I agree this should be patch/minor. I would suggest (for the patch version of this):
- SHOULD use JSON-LD for Extensions
- MAY include a JSON Schema URI in JSON-LD metadata
Or something of the like. I changed the issue title to remove "require" so we can hopefully get this out of "major".
@aaronesilvers The OWLs are not what they seem.
As far as the letter ordering... why is "Universal Coordinated Time" UTC? Just blame the French.
Howdy,
In W3C Social WG we work on Activity Streams 2.0 and base it on JSON-LD!
- http://www.w3.org/TR/2015/WD-activitystreams-core-20150129/
- http://www.w3.org/TR/2015/WD-activitystreams-vocabulary-20150129/
As participant of mentioned Social WG, Social IG (plus Social IG Liaison TF) and Credentials CG, I would happily join one of you calls to discuss AS2.0 and JSON-LD :telephone_receiver:
BTW I also try to help with clarifying extension mechanism in Schema.org, improving schema.org/Action sub tree and aligning work on AS2.0 and Schema.org (all mentioned above use JSON-LD)
- https://github.com/schemaorg/schemaorg/issues/284
- http://schema.org/docs/full.html#Action
- https://github.com/schemaorg/schemaorg/issues/220
- https://developers.google.com/+/api/moment-types/
Cheers!
I'm still in favour of adding a patch label to this alongside the major label cc @andyjohnson
@canweriotnow re "MAY include a JSON Schema URI in JSON-LD metadata" - can you give some more details either here, or on the forums, about what this means? An example would be good!
See also my comments here: https://groups.google.com/a/adlnet.gov/forum/#!topic/xapi-spec/8Zddb-cMPjc
I'm not sure what exactly he's referring to there; the way Open Badges includes a JSON schema URI is idiosyncratic and not based on any precedent (per the author of the concept). It uses an Open Badges specific namespace, too. If someone chooses to adopt a similar approach, they'll need to specify their own way (though it'd probably end up being similar to Open Badges' way).
I recommend we do not include any of this in the spec. It is entirely reasonable for these to proceed outside of the spec (there's nothing stopping anyone from doing them), and while they'd only be SHOULDs, incorporation of JSON-LD into the spec should be done in a more principled way rather than piecemeal.
Per the 11/18/2015 call, last chance to get anything changed for version 1.0.3. No changes currently planned as JSON-LD isn't quite a de facto standard(yet).
JSON-LD isn't quite a de facto standard(yet).
That is wrong. JSON-LD is a real standard: http://www.w3.org/TR/json-ld/
Yeah, while I don't think it makes sense to include any language about using JSON-LD in extensions in xAPI at this point, since that's already entirely allowed and it wouldn't provide any non-custom semantics (though that'd be worth exploring in future versions of xAPI), JSON-LD is not just already a standard, but one seeing a lot of adoption, which a number of other standards are basing themselves on.
@fugu13 it was the adoption question we briefly discussed on the call. Given that you are seeing a lot of adoption, is it worth recommending using json ld in this version?
I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.
But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.
+1 The spec community can and should start a research activity around the use (even universal use) of JSON-LD so we can roll the findings into the spec, but I don't think we should just push this as a potentially breaking change to current practice without the drivers and clear value mapped for the changes to recognize who's doing what with the spec (like certification).
Sent from Outlook
On Wed, Nov 18, 2015 at 1:13 PM -0800, "fugu13" [email protected] wrote:
I should make sure I'm clear: not adoption in xAPI Statements, just adoption in general of JSON-LD.
But to answer the question: No, since it is already completely allowed, and using it wouldn't provide any additional semantics for Statements. Best to wait, see if practices develop with it that are useful, then if they do, do a more thorough standardization of its use and interpretation in a future version of the spec.
— Reply to this email directly or view it on GitHub.
Russell has been a huge help in advising the vocab group on using linked data for xAPI vocabularies this past year and it is a good first step for us. We plan to push out a draft companion doc & primer next month for the spec community to review. This should help drive some of the practices in this direction, but modernizing the entire model of xAPI could be a much bigger undertaking than we realize. As Russell pointed out it isn't only about the statements.
Would the community like to see something like this initially funded?
ADL's FY16 BAA was just posted to Fed Biz Ops this week. The link to the BAA is: https://www.fbo.gov/notices/27450b5709d4d5c74091ceaffd9766c2. The solicitation number is: ADLBAA12001. Per the BAA, Quad Charts are requested to be submitted by 7 December 2015.
Leaving JSON-LD to the side (for the moment), what I'd really like to see come out of this is the ability for LRSs that parse extensions that declare a JSON-Schema via their IRI identifier to reject Statements with invalid (per the schema) extensions. The standards-wrangling is a sideshow, IMHO.
But if I'm crafting an AP, such as (I dunno, a flight simulator, since we've done that before) which uses an extension to map the X/Y/Z coordinates of the plane, I need to be able to ensure that Cleetus the slack-jawed yokel isn't going to use the same IRI to send extension data about his possum soup recipe when I'm trying to analyze simulated flight recorder data. So some mechanism for separating flight data from possum soup data is desirable.
I'm only looking for a MAY or perhaps SHOULD in 1.0.3, obviously a MUST is a 2.0 issue; if other LRSs want to accept possum soup recipes in from APs claiming to be flight simulators, that's their business. I just want to be able to reject Statements telling me how to gut and season a possum when I'm looking for pitch, yaw, and roll.
This is the part I think needs to be altered:
An LRS MUST NOT reject a Statement based on the values of the extensions map.
(From 4.1 Extensions)
An suggested alternate:
An Extension IRI MAY reference a JSON-Schema declaring acceptable format/values for the extension map. An LRS MAY reject a Statement based on an invalid extension map IFF a Schema is declared. An LRS MUST NOT reject a Statement based on the values of the extensions map if no Schema is available.
Seems reasonable @canweriotnow. Not looked into JSON-LD enough to know how to validate using the schemas, but I'm sure it's simple enough.
I think another point that is important in this is the practice of good IRI design and persistence. We plan to incorporate this in a draft companion spec for xAPI verbs,vocabs, etc. and update the draft guidance in this doc surrounding the creating of IRIs: https://docs.google.com/document/d/1RavkVwdzWQNszMXs8DMEth0bayAZRGBWWlSYVJtnC7M/edit
Any thoughts on this guidance?
In regards to this proposed update for the core spec, I recommend we be consistent with either saying "JSON-LD" or "JSON Schema." They aren't quite the same thing and could lead to confusion or inconsistent implementations by the community.
http://json-schema.org/ http://json-ld.org/
@jhaag75 You're absolutely right - This should really be two issues, one for JSON-Schema validation and another for JSON-LD support. I'm going to edit to clarify that this issue is really about allowing JSON-Schema validation of extensions, not full JSON-LD support.
@andyjohnson take a look at https://github.com/adlnet/xAPI-Spec/issues/577#issuecomment-160516922, I'd be happy to make it a PR if the language seems reasonable.
For 1.0.3 I worry that this is technically a breaking change, though thinking pragmatically it's only breaking for activity providers who are using an extension that has a hosted schema and they are not following that schema. I suspect that's approximately zero activity providers. Given that a test suite isn't going to use extensions with defined schemas and the way @canweriotnow has arranged the MAY/MUST, this doesn't seem breaking for LRSs either.
If we do go ahead with the change, some specific comments on the wording proposed by @canweriotnow
- I don't want to introduce "IFF" in the document. If we were going to use it in a lot of places then it might be useful, but otherwise it adds more complexity than it saves.
- There needs to be a bunch more explanation about JSON schema hosting, probably in the metadata section.
- We need to tighten up the language around a schema being declared and a schema being availability, which are two distinct concepts. I'd prefer the requirements to be around availability of the schema with the caveat that availability means that either the LRS is able to fetch the schema from the extension IRI, or otherwise access the schema (e.g. from a cached copy, or some other unspecified source).
- Do we need to say something about the content type requested?
Most of what I'm suggesting adding would go in the metadata section, so we'd need to add a "see metadata section" somewhere in the extension requirements.
As a side note, on your Cleetus example, you could also filter in just data from known good sources using authority.
@garemoko Makes sense. I'll start on a PR that incorporates your feedback, might want to get some feedback from you on the branch as it progresses, but I'm sure I can have it ready in a few days... just have to get one pressing client issue out of the way and I can concentrate on doing this up right.
@canweriotnow feel free to open an unfinished PR if you like. Probably the best way to get in-progress feedback.