Re: Agenda: JSON-LD Telecon - Tuesday, October 2nd 2012

We might want to spend a couple of minutes discussing how we might automatically process application/microdata+json.

Gregg Kellogg
gregg@greggkellogg.net

On Oct 1, 2012, at 8:36 AM, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 10/01/2012 10:18 AM, Markus Lanthaler wrote:
>> I saw you reassigned the "objectify" issue [1] to the JSON-LD.next 
>> milestone. This worries me a bit as we also moved framing there. I 
>> wouldn't like to see a JSON-LD API that *requires* another API on top
>> of it to be usable in practice.
> 
> A few high-level thoughts:
> 
> 1. This feature is not necessary in order for /JSON-LD/ to be
>   usable in practice. We expect most developers and systems to not
>   have to modify the incoming/outgoing document at all (as it adds
>   more complexity, unnecessarily in most cases). The /JSON-LD API/
>   is useful with just .compact(), .expand(), .toRDF(), and .fromRDF().
>   It would be nice to have this feature, but the API is useful without
>   it.
> 2. We don't have a proposed solution for .graphify()/.link()
>   /.objectify() and we're running out of time to add it to the spec,
>   get test cases in shape, and get implementations before REC.
> 3. This 'layering' approach is a best practice when it comes to
>   writing Web-based browser APIs. It lets you get something out of the
>   door while keeping the door open for extensions to be added on in
>   the future.
> 4. At some point, we have to draw a 1.0 line in the sand and put
>   features that are probably not going to make it on the other side
>   of that line so that we can focus on the features that have
>   proposals, spec text, and are already in the spec.
> 
>> The problem is that the same information can be expressed in various
>> ways and apart from flattening it and then looping over it there's
>> no way to access it directly. I think that was one of the problems 
>> RDF/XML faced and I wouldn't like to see JSON-LD going down the same
>> path - especially considering that we do have an API.
> 
> I agree. If somebody would like to volunteer to write spec text, write
> an implementation and write tests... we could more easily move on this.
> Nobody has done this work at this point and nobody (with enough time to
> move quickly on it) was volunteering to do it.
> 
> I'll also note that .objectify()/.graphify() won't solve the .frame()
> problem... just because you have an in-memory model doesn't mean that
> it's easy to access the data on that in-memory model.
> 
>> I would like to discuss this decision briefly, either in the 
>> beginning, the end or also in another telecon after we are done with 
>> the other issues.
> 
> +1 - We'll add it to the beginning of the Agenda.
> 
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> President/CEO - Digital Bazaar, Inc.
> blog: The Problem with RDF and Nuclear Power
> http://manu.sporny.org/2012/nuclear-rdf/
>

Received on Monday, 1 October 2012 16:40:53 UTC