Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Fri, Aug 10, 2012 at 1:39 PM, Markus Lanthaler markus.lantha...@gmx.net wrote: 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. That's a problem right there. It means that JSON-LD requires more consumer complexity than application/microdata+json. -- Henri Sivonen hsivo...@iki.fi http://hsivonen.iki.fi/
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
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
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
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
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Thursday, August 09, 2012 1:18 AM, Ian Hickson wrote. On Wed, 8 Aug 2012, Markus Lanthaler wrote: I was wondering whether it was considered to use JSON-LD [2] instead of creating application/microdata+json. The resulting output would be more or less the same. It wasn't. What would be the purpose of doing so? 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. 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. It has support for string internationalization, data typing, lists etc. 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. 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?). 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. [1] http://json-ld.org/spec/latest/json-ld-framing/ [2] http://json-ld.org/spec/latest/json-ld-api/ [3] http://json-ld.org/playground/ -- Markus Lanthaler @markuslanthaler
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Thu, 9 Aug 2012, Markus Lanthaler 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. 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? 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? 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? 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. 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. 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. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Was is considered to use JSON-LD instead of creating application/microdata+json?
On Wed, 8 Aug 2012, Markus Lanthaler wrote:
I was wondering whether it was considered to use JSON-LD [2] instead of
creating application/microdata+json. The resulting output would be more
or less the same.
It wasn't. What would be the purpose of doing so?
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?
For example the following application/microdata+json document:
{
items: [
{
id: http://example.com/id1;,
type: [ http://example.com/type1; ],
properties: {
property1: [ value1 ],
property2: [
{
id: http://example.com/id2;,
type: [
http://example.com/type2;,
http://example.com/type3;
],
properties: {
property3: [ http://example.com/value3; ]
}
}
]
}
}
]
}
Could be expressed in JSON-LD as
{
@graph: [
{
@id: http://example.com/id1;,
@type: [ http://example.com/type1; ],
property1: [ value1 ],
property2: [
{
@id: http://example.com/id2;,
@type: [
http://example.com/type2;,
http://example.com/type3;
],
properties: {
property3: [ { @id: http://example.com/value3; } ]
}
}
]
}
]
}
Or, by aliasing JSON-LD's keywords even as which is almost exactly the same
as the application/microdata+json counterpart:
{
@context: {
id: @id,
type: @type,
items: @graph
},
items: [
{
id: http://example.com/id1;,
type: [ http://example.com/type1; ],
property1: [ value1 ],
property2: [
{
id: http://example.com/id2;,
type: [
http://example.com/type2;,
http://example.com/type3;
],
properties: {
property3: [ { @id: http://example.com/value3; } ]
}
}
]
}
]
}
That seems like it is strictly more complicated (trivially so, but still).
What is the advantage?
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
