All things being equal, I would prefer a Lisp-based format rather than JSON, yes. (My involvement with that approach goes back 25 years: https://en.wikipedia.org/wiki/Electronic_Design_Interchange_Format )
But EDN + this convention would be something only my software would support, and anyone I could convince. JSON-LD is a fairly simple standard, already has a good and growing level of support, and because it is "just JSON" can be used directly by a lot of software without any awareness of the LD aspect. Everything is a compromise. Pro's and con's all around. On Sunday, June 1, 2014 12:04:50 AM UTC-7, Jozef Wagner wrote: > > 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 > <https://www.google.com/url?q=https%3A%2F%2Fgist.github.com%2Fwagjo%2Fd6419a289a64c503010c&sa=D&sntz=1&usg=AFQjCNH4biGF4OXzCJVVQ4AUHE_H_srSJg> > > 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.
