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

[Ian Hickson]

On Fri, 10 Aug 2012, Markus Lanthaler wrote:
> 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?

There'd be no way to distinguish a microdata drag-and-drop payload from 
any other JSON-based (or in the case of what you're proposing, 
JSON-LD-based) payload in the dropzone="" filtering.


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

Then there'd be no way to determine if the payload was generated by the 
microdata extractor or not.


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

What JSON-LD API? I'm not aware of any browsers that have such a thing. 
And why would we want to require that authors use yet another API instead 
of just using straight JavaScript, as you can with JSON?


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

I don't understand what you mean by "flexible and expressive". Could you 
give an example of how JSON-LD is more flexible than JSON? I'm really 
confused as to what you're saying here.


> JSON-LD could also be used to extract RDFa (lossless).

That doesn't seem like a benefit.

(Note that microdata and RDF have different data models and cannot be 
directly mapped from one to the other. It is highly unlikely that any 
other format can actually represent both of them without either some sort 
of data loss or a dramatically more complicated data model than microdata, 
both of which would be bad.)


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

Could you give a concrete example of a problem this solves? I'm finding it 
different to understand what you are proposing.


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

That sounds like the pie-in-the-sky reasoning that underlies most RDF 
arguments. :-) Could you point to a concrete example of an actual 
application that would benefit from having a single field have multiple 
types?

In the case of the example you give, I think applications would in general 
benefit far more (in terms of ease of implementation and maintenance) from 
just having one field that describes the author in terms of the author's 
name, and one field that gives an identifier that can be used to look up 
the author in the database, rather than having a single field that can do 
one or the other but not both, or that can do both but is sometimes a 
multivalued array and sometimes just one value and you have to introspect 
each value to work out what each entry is.


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

I see no value in doing these changes. They just make the format more ugly 
with more punctuation without adding any new features, as far as I can tell.


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

>From what I can see, it's got prefix indirection, tries to use URLs for 
field names, it makes it highly likely people will introduce bugs like 
directly reading "ex:contains" instead of expaning each name to check what 
it is, it makes it impossible for JSON syntax checkers to automatically 
catch duplicate terms, and it is no more able to represent microdata than 
the simple format we have now. I really don't understand why we would want 
to go there. It's got all the problems that RDFa had which are why we 
started doing microdata in the first place.


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

I disagree with "just as well".

You're right that there's already a format for doing this. It's JSON. No 
need to layer additional stuff on top of it, IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'