[whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?

[Markus Lanthaler]

On Thursday, August 09, 2012 4:53 PM, Ian Hickson wrote:

> > > The only reason there's a MIME type at all (rather than just using
> > > JSON's directly) was to enable filtering of copy-and-paste and
> > > drag-and-drop payloads; would JSON-LD enable that also?
> >
> > Sure, I see no reason why not.
> 
> Could you give an example of how? I don't understand how it would work
> if we re-use an an existing MIME type. If you have any concrete examples
> I could look at that would be ideal.

Maybe I'm missing something but what would be the difference of re-using an
existing MIME type?

Looking at the drag and drop API the only thing that would need to be
changed is the "drag data item type string" from "
application/microdata+json" to "application/ld+json" in [1]. The advantage
in doing so would be that a drop handler could use the JSON-LD API to
reframe the data so that it can be used more easily.


> > > That seems like it is strictly more complicated (trivially so, but
> > > still). What is the advantage?
> >
> > Well, I would say there are several advantages. First of all, JSON-LD
> is
> > more flexible and expressive.
> 
> More flexible and expressive than what?

Than application/microdata+json. JSON-LD could also be used to extract RDFa
(lossless).


> > It has support for string internationalization, data typing, lists
> etc.
> 
> How would this manifest itself in this context? Are you suggesting that
> we
> should change the microdata to JSON serialisation rules somehow?

Since microdata doesn't support that, it isn't really needed in that
context. But it could harmonize the result with a lossless extraction of
RDFa for example or come very handy when interacting with Web services
exposing JSON-LD.


> > It also allows to distinguish between IRIs and literals (which isn't
> the
> > case for application/microdata+json) which is important for Linked
> Data
> > application.
> 
> Could you give an example of how this would help an application?

You could imagine an application that manages books and their authors. If
the author is specified in the form of an IRI, the application could render
the information in the form of a hyperlink or go even a step further and try
to automatically fetch more information about that author.


> It would help if you described what precise changes you would like to
> see
> to the algorithms, so that I better understood the implications here.

The changes are trivial. In the drag and drop API algorithms all that have
to be changed is the MIME type. In the microdata API [2] the changes would
be something like this:

.. 4. Add an entry to result called "items" ...

++ 5. Add an entry to result called "@context" whose value is the following
object
  {  "@vocab": "" }

.. 6. Return the result of serializing result to JSON ...


If you don't like to use "@id", "@type", and "@graph" instead of "id",
"type", and "items" add a step after step 4 of the current algorithm:

.. 4. Add an entry to result called "items" ...

++ 5. Add an entry to result called "@context" whose value is the following
object
  {
    "id": "@id",
    "type": "@type",
    "items": "@graph"
  }

.. 6. Return the result of serializing result to JSON ...



If the @-keywords are fine, you don't have to add a context, instead the
following steps have to be changed in the algorithm:

-- 3. If the item has any item types, add an entry to result called "type"
...
++ 3. If the item has any item types, add an entry to result called "@type"
...

-- 4. If the item has a global identifier, add an entry to result called
"id" ...
++ 4. If the item has a global identifier, add an entry to result called
"@id" ...


In both cases you would have to drop step 7

-- 7. Add an entry to result called "properties" whose value is the object
properties.

and change steps 6.3.1 and 6.3.2 to use "result" directly

-- 1. If there is no entry named name in properties, then add an
--    entry named name to properties whose value is an empty array.
-- 2. Append value to the entry named name in properties.

++ 1. If there is no entry named name in result, then add an
++    entry named name to result whose value is an empty array.
++ 2. Append value to the entry named name in result.


> > Secondly, there is an API for JSON-LD to reframe [1] a document into
> a
> > shape that might be easier to work with in a web app (I think that's
> the
> > whole point of microdata+json or am I wrong?).
> 
> I don't understand what this means.

Well, for example you could transform a list of books and chapters of those
books to a nested structure with the books at the top level and the chapters
as children. Have a look at the example in the JSON-LD playground [3] (click
on Framing Examples: Library at the top right).


> > Other API calls allow e.g. to convert to and from RDF [2]. If you are
> > interested, there is an online JSON-LD playground [3] where you can
> play
> > with the various API calls. Last but not least it would also make web
> > developers life easier if there are fewer formats to support/learn.
> 
> Currently, the data is just stored as JSON, it's not a new format. It's
> only a new MIME type to allow easier filtering in the drag-and-drop
> API.

Yes, and my argument is that there is already a REC track format for exactly
that use case that could be used just as well for the drag-and-drop API.


[1]
http://www.whatwg.org/specs/web-apps/current-work/multipage/dnd.html#drag-an
d-drop-processing-model
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/microdata.html#j
son
[3] http://json-ld.org/playground/



--
Markus Lanthaler
@markuslanthaler