How about format which can represent either graph or structure, depending on users needs? I would argue that EDN is more suitable for linked data than JSON is. Its support for identifiers and tagged elements allows for pretty straightforward serialization of linked data. See https://gist.github.com/wagjo/d6419a289a64c503010c for one possible approach.
Jozef On Sunday, June 1, 2014 2:18:00 AM UTC+2, Patrick Logan wrote: > > Now *that* is a pretty reasonable comparison. I would quibble here and > there: I don't find JSON-LD as heavy-weight as you; the benefit of > universal identifiers is an advantage in the domains I work in; and the > whole graph vs. struct debate... it's a lot easier to represent a struct as > a simple graph than it is to represent a graph as "structs + conventions", > etc. But those are all needs-based trade-offs. The comparison is fair. > > > On Saturday, May 31, 2014 3:45:24 PM UTC-7, Jozef Wagner wrote: >> >> Well the suggestion to consider JSON-LD was really out of place. Compared >> to JSON-LD, EDN belongs to the category of lightweight, schemaless and >> streaming friendly data serialization formats. JSON-LD is closer to e.g. >> Turtle or RDF/XML. It serves a different purpose and has different goals >> than EDN. >> >> JSON-LD is a representation of labeled, directed graph of nodes [1]. The >> smallest thing you can represent in it is a graph of nodes. You may make >> analogy between IRI [2] node and EDN map, but note that in JSON-LD, every >> property must be a valid IRI. >> >> Besides other IRI nodes as a property values, JSON-LD supports integers, >> floats, strings, booleans and custom types through typed values, which is >> something like edn tagged elements but can be only applied to string >> values. >> >> JSON-LD has no built in support for nils and characters, and no support >> for random-access vectors. JSON-LD has a concept of unordered and >> ordered collections (which is an improvement compared to RDF [3]), which >> corresponds to EDN set and list types. >> >> While the motivation behind JSON-LD is to be a simple Microdata/RDFa >> alternative for web services, over engineered technologies lurks underneath >> and they sometimes leak through the JSON-LD facade. I'm pessimistic that it >> will slip (again) into unnecessary complex ontologies and rigid schemas no >> one wants to use. >> >> [1] http://www.w3.org/TR/json-ld/#data-model-overview >> [2] http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/#dfn-iri >> [3] see section 'Decision 3' at >> http://manu.sporny.org/2014/json-ld-origins-2/ >> >> Jozef >> >> On Saturday, May 31, 2014 5:32:55 PM UTC+2, Patrick Logan wrote: >>> >>> Brilliant analysis. >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
