JSON-LD & Web Credentials - illustrated videos by Manu Sporny

[☮ elf Pavlik ☮]

Howdy,

I would strongly encourage that everyone Linked Data and JSON-LD checks
out illustrated videos published by Manu Sporny
https://www.youtube.com/channel/UCnaA8lQHipp7D6nedkpdE0A

I suggest watching them in order

1. What is Linked Data? http://youtu.be/4x_xzT5eF5Q
2. What is JSON-LD? http://youtu.be/vioCbTo3C-4
3. JSON-LD: Core Markup http://youtu.be/UmvWk_TQ30A
4. JSON-LD: Compaction and Expansion http://youtu.be/Tm3fD89dqRE
5. Linked Data Signatures http://youtu.be/QdUZaYeQblY
6. Credentials on the Web http://youtu.be/eWtOg3vSzxI

Enjoy!

[Andrew Downes]

Thanks for these links!

From skimming through the first two videos, my understanding is that JSON-LD is a specification designed for non-standard APIs that return JSON so that the structure of these JSON objects can be described to software consuming that data. It seems to be trying to solve the same problem that we already solve by having a specified common API. One area of Tin Can were we do not have a specified structure is extensions and it seems to me that we're already (accidentally?) using JSON-LD for extensions as extensions are always mapped to IRIs. The other area is documents where I personally always recommend using IRI for keys, but it's not required by the spec. 

Some follow up questions:

• Is there any benefit to adopting JSON-LD for the standardised parts of the spec? Am I missing anything here? 
• Should we recommend that adopters use JSON-LD for extensions (where the extension contains an object)?
• Should we also recommend JSON-LD for JSON documents in the Document APIs?
• If we do make recommendations to use JSON-LD for extensions and/or documents, is the JSON-LD spec mature/complete enough that we can just say "use JSON-LD" or do we need to give details as to how adopters should implement JSON-LD? 
• Are the JSON-LD key words ubiquitous and stable enough that we should use these, or should we use IRIs for everything? My initial view is that we *should* use the JSON-LD key words as it seems that JSON-LD has a lot of noise at least (if not actual adoption), though I'm disappointed that the authors of JSON-LD didn't use IRIs for these. 

If we can get this worked out and agreed, it may be that the recommendations mentioned above could be made in 1.0.3. 

[Andrew Downes]

Just realised Jason Lewis already proposed something along these lines for extensions here: https://github.com/adlnet/xAPI-Spec/issues/577#issuecomment-69069336

[☮ elf Pavlik ☮]

Hi Andrew,

I forwarded your questions to JSON-LD mailing list and hope someone will
have time to write in depth answer very soon.
https://lists.w3.org/Archives/Public/public-linked-json/2015Mar/0014.html

For now I can only bring to your attention that JSON-LD 1.0 has already
official W3C *Recommendation* status http://www.w3.org/TR/json-ld/

It has also very rapid adoption, among many including
* http://blog.schema.org/2013/06/schemaorg-and-json-ld.html
* http://blog.sgo.to/2014/09/schemaorg-actions-implementations.html
* http://specification.openbadges.org/
* http://www.w3.org/TR/ldp/
* http://www.w3.org/TR/activitystreams-core/
* http://www.w3.org/TR/activitystreams-vocabulary/
* http://www.hydra-cg.com/spec/latest/core/
* http://w3c.github.io/web-annotation/model/fpwd/
etc.

Not to mention already existing tooling
* http://json-ld.org/#developers

Please expect more information on this thread soon!

Cheers :)

On 03/10/2015 12:57 PM, Andrew Downes wrote:
> Thanks for these links!
>
> From skimming through the first two videos, my understanding is that
> JSON-LD is a specification designed for non-standard APIs that return JSON
> so that the structure of these JSON objects can be described to software
> consuming that data. It seems to be trying to solve the same problem that
> we already solve by having a specified common API. One area of Tin Can were
> we do not have a specified structure is extensions and it seems to me that
> we're already (accidentally?) using JSON-LD for extensions as extensions
> are always mapped to IRIs. The other area is documents where I personally always
> recommend using IRI for keys

> <http://tincanapi.com/2015/03/09/deep-dive-interoperability-document-apis?utm_source=tincanapi_com&utm_medium=google-group&utm_term=andrew&utm_content=blog&utm_campaign=deep-dive-interoperbility-document-apis?pmc=em-1>,

> but it's not required by the spec.
>
> Some follow up questions:
>

> - Is there any benefit to adopting JSON-LD for the standardised parts of

> the spec? Am I missing anything here?

> - Should we recommend that adopters use JSON-LD for extensions (where

> the extension contains an object)?

> - Should we also recommend JSON-LD for JSON documents in the Document
> APIs?
> - If we do make recommendations to use JSON-LD for extensions and/or

> documents, is the JSON-LD spec mature/complete enough that we can just say
> "use JSON-LD" or do we need to give details as to how adopters should
> implement JSON-LD?

> - Are the JSON-LD key words ubiquitous and stable enough that we should

> use these, or should we use IRIs for everything? My initial view is that we
> *should* use the JSON-LD key words as it seems that JSON-LD has a lot of
> noise at least (if not actual adoption), though I'm disappointed that the
> authors of JSON-LD didn't use IRIs for these.
>
> If we can get this worked out and agreed, it may be that the
> recommendations mentioned above could be made in 1.0.3.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to xapi-spec+...@adlnet.gov.
>

[Andrew Downes]

Thanks Elf! That's helpful. 

[Craig Wiggins]

i'm just now getting around to watching these videos. Thanks, elf!