- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 18 Mar 2014 22:56:52 +0000
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- Cc: public-hydra@w3.org
> It would be interesting to benchmark that.. I was thinking of JSON-LD
> representations of the following form
>
> [
> { "@id": "http://subject", "http://predicate": { "@value": "object" },
> { "@id": "http://subject", "http://predicate": { "@id": "http://object" },
> …
> ]
(Diverging a bit here to to JSON-LD, sorry in advance.)
Aha, that's something different.
My current approach to serve Turtle is streaming;
the current approach to serve JSON-LD is
capturing the Turtle stream, then converting the whole (non-streaming):
https://github.com/LinkedDataFragments/Server/blob/master/lib/JsonLdFragmentWriter.js
However, the above _could_ be generated in a streaming way;
and then also parsed. But do streaming JSON-LD libs exist?
In any case, I need the triples in-memory as triples
to do querying, so really { s: … p: … o: … } things.
> Probably not. However, *if* we decide to support them, I would prefer to
> special-case qnames. I'm offline at the moment but I think the CURIE spec
> recommends wrapping them in square brackets [prefix:suffix].
That might even not be necessary, as indicated by Greg:
https://github.com/HydraCG/Specifications/issues/30#issuecomment-37763839
>> It depends on how we'd express property paths.
>
> I think the simplest thing would be to use lists
OK, let's postpone this until we have a concrete syntax.
>> It would be needed we'd also need to detail how each part of the graph
>> can be accessed, i.e., what kind of fragments your are offering.
>> Without that, no query plan, without query plan, exponential times
>> (or you'd have to download the whole thing before querying it).
>
> Well, the ApiDocumentation along with property ranges and supportedProperty
> kind of expresses that information, doesn't it?
That could be, yes.
Any concrete examples I could investigate?
Cheers,
Ruben
Received on Tuesday, 18 March 2014 22:57:28 UTC