- From: Gregg Kellogg <gregg@greggkellogg.net>
- Date: Wed, 11 Dec 2013 08:12:48 -0800
- To: Ruben Verborgh <ruben.verborgh@ugent.be>
- Cc: Markus Lanthaler <markus.lanthaler@gmx.net>, "public-rdfjs@w3.org" <public-rdfjs@w3.org>
Gregg Kellogg gregg@greggkellogg.net On Dec 11, 2013, at 7:59 AM, Gregg Kellogg <gregg@greggkellogg.net> wrote: > On Dec 11, 2013, at 7:47 AM, Ruben Verborgh <ruben.verborgh@ugent.be> wrote: > >>> Turtle is not a standard yet. It's a Candidate Recommendation >> >> Oh yeah of course, I keep treating the CR as a standard. Shouldn't do that. >> (Still hoping they drop the SPARQL keyword syntax.) >> >>> That's a valid point. In this specific case I would just define a profile >>> which specifies the structure the document has to adhere to. Since JSON-LD >>> has a profile media type parameter you can even expose that information on >>> the wire. >> >> Brilliant, that would be all we need. >> Could it be such that: >> - no nesting is allowed (cf. earlier example you posted) >> - no prefixes are allowed >> That would give us simple and fast parsers. >> And those libraries that have full JSON-LD can just use that. > > This is essentially expanded flattened form; it's also what the JSON-LD FromRdf algorithm generates. Note, however, that lists are first-level, and don't use first/rest linking. Note, however, that there's nothing that would prevent us from using a triple form of expanded JSON-LD, where each triple is in it's own object. Also, rdf:first/rdf:rest can be used in the JSON-LD representation, so use of @list is not necessary; for JSON-LD, toRdf would handle this just fine. Note that Named triples (quads) would require a bit more embedding, e.g.: {"@id": "http://graph-name", "@graph": {"@id": "http://subject", "http://predicate": [{"@id": "http://object"}]} Gregg > Gregg > >> Best, >> >> Ruben >>
Received on Wednesday, 11 December 2013 16:13:25 UTC