- From: Jacopo Scazzosi <jacopo@scazzosi.com>
- Date: Sun, 23 Jan 2022 23:08:03 +0100
- To: Martynas Jusevičius <martynas@atomgraph.com>
- Cc: Melvin Carvalho <melvincarvalho@gmail.com>, Sebastian Hellmann <hellmann@informatik.uni-leipzig.de>, Jonas Smedegaard <jonas@jones.dk>, Kingsley Idehen <kidehen@openlinksw.com>, public-webid <public-webid@w3.org>
Hello all, > I do not understand the notion that anyone should be implementing > their own conneg or JSON-LD parser. Not everyone uses Java, JavaScript or any of the languages listed at https://json-ld.org . Production-ready support for JSON-LD is not as easily achieved outside of Java and JavaScript. > The "no dependencies" constraint is completely self-imposed and I > would argue at odds with general software development practices, > especially in an enterprise setting (I've worked at SAP for 5 years). The "no dependencies" argument, which is fortunately more nuanced than a binary one, is definitely self-imposed and correctly so (IMHO), particularly when it comes to engineering software that needs to run remotely, embedded and unsupervised, for years. In any case, I do not want to argue in favor or against a specific approach to software engineering but merely point out that different approaches do exist and that a spec such as WebID should aim for the common denominator, which does not (easily) include conneg and JSON-LD parsing. > As such, this sort of structured representation has several advantages: it > is easy to extend (as shown with the Solid case), it is easy to deploy as a > static resource and (arguably) this format would be easy for constrained > devices to consume, as was suggested in the IoT case. In fact, a client > application would have no real need for an RDF parser at all -- it merely > needs to read the document as JSON and verify the value(s) in the @context > array; no full JSON-LD parser is necessary. But if a client wants all the > semantic richness of the full RDF graph, that option is still open by using > a JSON-LD 1.1 parser. Very nice! Thank you Aaron for coming up with this example. Seems like a good tradeoff, I really like the direction. I am personally in favor of Turtle as the default and mandatory serialization format for both clients and publishers but I'd be happy with a WebID 2.0 spec based on what you suggest. Best regards, Jacopo.
Received on Sunday, 23 January 2022 22:08:19 UTC