RE: JSON-LD in HTML

On Sunday, March 17, 2013 4:46 PM, Gregg Kellogg

> > just saw this thread and haven't thought much about it yet..
> > So just two questions (no offence intended):
> 
> (Why would I take offense to perfectly reasonable questions ?)

Because when I'm sending emails in a rush I often sound aggressive without intending it.


> > - What problem are why trying to solve here? I mean which use case
> are we
> > trying to address? Why would someone want to embed JSON-LD in HTML? I
> > haven't seen much JSON embedded into HTML in the wild.. and JSON is
> > extremely popular.
> 
> As I mentioned in the lead-in, HTML-based markup for expressing meta-
> data (think SEO) has been shown to be error-prone. Embedding JSON-LD is
> useful as an alternative to RDFa/microdata which is hopefully less
> error prone. Plus, an advantage of JSON-LD, is that common problems in
> expression can often be addressed by updating the context.

OK.. makes sense. The thing that irritated me in the initial mail was the prominence of "extraction of RDF" which is, IMO, most of the time, the last thing people are concerned about. Whereas extracting the JSON to use it in a JavaScript webapp wasn't even mentioned.


> > - If we are embedding JSON-LD (not JSON), why do we need to add
> another
> > mechanism to reference a context? People embedding JSON-LD obviously
> need to
> > understand it.. so what's the problem with @context?
> 
> Good question. One reason is that when multiple objects are used,
> particularly when flattened, this requires using the @graph key in the
> top-level object. Anything else (other than @context) may change the
> meaning of the data. And, you might reasonably think that if the
> subtleties of microdata are challenging, the the subtleties of @graph
> may also be challenging, adding the context to the container means that
> multiple objects can just be expressed in array form, without needing
> @graph. The idea is to make it as easy as possible for people to
> express metadata in HTML, and I think this comes pretty close.

and

On Sunday, March 17, 2013 4:36 PM, Manu Sporny wrote

> > - If we are embedding JSON-LD (not JSON), why do we need to add
> > another mechanism to reference a context? People embedding JSON-LD
> > obviously need to understand it.. so what's the problem with
> > @context?
> 
> Good question... but if we use data-context, it might not be too bad
> since it's a non-normative feature. If it were normative, I'd say that
> we should introduce a new "@context" attribute name. I do agree with
> your point about not re-using data-*, though I think it's the least of
> all evils that Ivan outlined.
> 
> One argument is to use @data-context for now, and if the mechanism
> becomes popular, we standardize @context. Then JSON-LD-in-HTML
> processors would need to load from @data-context or @context (where the
> latter overrides the former if both are on the same element). I'd
> expect
> that we'd do this in JSON-LD 1.1 /if/ this feature becomes popular.

I didn't mean a new "context" attribute but the use of our "@context" keyword in the JSON-LD document.

If the context is most of the time external, as the example and description suggests, the external context could include an alias "@graph" to "data". People will anyway need to know which terms to use. So requiring a top-level data property isn't problematic IMO.

Top-level arrays are rarely used in JSON in my experience (in some circumstances this even leads to security vulnerabilities). So the template for the document would look as follows:

{
  "@context": "http://example.com/context.jsonld",
  "data": ... put your data here ...
}

The advantage would be that you could copy-paste that fragment to a file and serve it as application/ld+json which wouldn't be possible with data-context. It also makes it much easier to copy-paste such a fragment to the JSON-LD playground e.g.

Regarding the special characters (<, >, &, etc.): I think it might be possible to work around this using \uXXXX escapes  but I haven't checked it yet.


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Monday, 18 March 2013 15:21:04 UTC