Re: Compacting on ActivityStreams receive in the API?

On 11/23/2014 09:18 PM, Christopher Allan Webber wrote:
> Hello,
Hi Christopher o/

> 
> I'm working on a minimal experiment that I'm hoping to use to track the
> standards as we develop them in this working group (it's currently a toy
> rather than a real implementation... I'm not sure that it'll be a fully
> useful implementation yet, but it'll be nice if it will be).
Awesome! How do you plan to persist data? (relational | document |
key-value | graph | ... )

> 
> This lead me to hit a point we've discussed, but I don't think have
> specified for sure (?)... what's the plan around compacting incoming
> data?  It's reasonable to assume that we should compact any json-ld
> before sending across the wire in the federation and social APIs... but
> what about incoming data in the social API?  Should we "just assume"
> it's already compacted, or should we run it through the compacting tool
> anyway to enforce that it is?
To my understanding we don't want to require everyone to use JSON-LD
processing algorithms[1]. If some system treats AS2.0 as regular JSON,
it will pretty much always work with representation equivalent to
JSON-LD /compacted/ form. On the other hand, systems understanding RDF
will often work with other JSON-LD profiles[2]. For example, myself I
persist all the data in a triple store, later when serializing certain
subset of those triples to JSON-LD I need to output it in /compacted/
form. This way other systems, which once again don't have to support
JSON-LD algorithms, can expect it in a form which they can work with.

While you can work with AS2.0 ignoring JSON-LD processing, I would
encourage you to still give a shot to some of the libraries listed on
http://json-ld.org/

HTH


[1] http://www.w3.org/TR/json-ld-api/
[2] http://www.w3.org/TR/json-ld/#iana-considerations

Received on Sunday, 23 November 2014 21:22:57 UTC