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

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

What I meant is that it is necessary if you don't know the shape of the data. If you have a tight coupling (think, contract) between the consumer and the producer you are right, you can use the JSON-LD as it... but you could as well use plain-old JSON instead because in that case JSON-LD doesn't give many advantages that would be worth the added complexity.


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

Time is indeed a problem.. So maybe trying to simplify framing in order to get in shape for a 1.0 release would be easier.


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

True, but I see this (or a variation thereof) as a fundamental feature that shouldn't be missing in the 1.0 API as it could impact adoption negatively.


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

Agree also with this.. but again, I see this as a more fundamental requirement than some other features we have been adding lately.


> > 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 have an implementation of this in my processor ([1], [2]). I also have a fairly complete test suite [3]. My implementation doesn't support named graphs yet as I couldn't get my head around it yet. 


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

That's true, therefore I added a JSON-LD document class which has methods like getNodes(), getNode(id) to facilitate that a bit. I don't know yet which other methods would be needed in practice. You can actually get quite far by just this and the fact that reverse relationships are also in-memory.


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

Great :-)


[1] https://github.com/lanthaler/JsonLD#usage
[2] https://github.com/lanthaler/JsonLD/blob/master/Processor.php#L190
[3] https://github.com/lanthaler/JsonLD/blob/master/Test/DocumentTest.php



--
Markus Lanthaler
@markuslanthaler

Received on Monday, 1 October 2012 17:11:28 UTC