- 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