Code of Conduct: https://github.com/solid/process/blob/master/code-of-conduct.md - Website: https://solidproject.org/ - Repos: https://github.com/solid/
Thanks @csarven that's helpful. One of my concerns with JSON-LD is that it might lead devs astray in terms of the value and use of RDF.
Firstly, assuming RDF tools and libraries are more relevant to RDF and Semantic Web applications than JSON-LD tools and libraries (since JSON-LD was built for other purposes and with Semantic Web 'not even a consideration', at least to begin with). So RDF tools would I think lead devs towards uses, models and communities that RDF targets, and would I anticipate encourage practices that support the Semantic Web, and the application independence and interoperability that is fundamental to Solid. Whereas use of JSON-LD libraries and tooling could in turn discourage those desirable things.
Secondly, even if those concerns are not shared, I am at least as concerned if devs try to create JSON-LD with or without a 'dedicated library' and JSON-LD specific tooling. JSON-LD is not necessarily conformant if I understand correctly, whereas one hopes at least that any Turtle, n3 (or other conformant representations) generated by a 'dedicated library' would generate a conformant representation. I don't know if one can even be sure that JSON-LD tools and libraries will produce conformant JSON-LD, presumably not. And if JSON-LD is generated without tools it is even more likely to contain RDF bugs. So I see the need for a dedicated library as helping devs get things right, and a non JSON-LD library as preferable to a JSON-LD library at that, for improving outcomes including interoperability.
I can see why people familiar with JSON in the browser would be attracted to JSON-LD, but am concerned if that attraction might be a siren voice leading the unwary away from what might serve them better in the long term. Those are my thoughts in two large nutshells, but I admit I don't know enough to be confident of those positions, so any corrections and comments on this would be helpful. Thanks for reading!
@csarven you are right that it is about the language. That’s why when you make what people call a NamedNode in the RDF grpah, the rdflib function was $rdf.sym() as it generates a symbol in the language.
At the RDF level, there is an isomorphism between the graph and turtle. It is useful to use the mental tools we have both for thinking about graphs and thinking in a language, and turtle as the language works well.
( In fact but most of my coding day I am thinking in the language, and the language is strctly N3. For me N3 is a complete langauge, and turtle a useful subset which happens to map to graphs and which we use at the data interchange layer. But n3 I can use for more stuff, like rules, and it is nice to have one a smooth extension of the other. But most of the bulk of the stuff I read and write ends up as being in Turtle.)
I think it is valuable for developers working on things like Solid to be fluent in turtle. To be able to say things like
:child a rdf:Property; s:label “child’; owl:inverse [ s:label “parent”]. (meaning “child is a property, whose label is “child” ,and which has an inverse whose label is “parent”) where I expect people to be happy reading the [ ] clauses as a core part of the langugage. Not having to draw a graoh with a bnode in on the whiteboard. We developped N3 first as a language for IRC chat and whiteboards where we wanted to be expressive and concise without having to draw circles and arrows. When you use turtle you are talking about things, not javascript objects. There is an important difference. Your thinking and your code should be about things: people, events, relationships. Not about symbols. Not about nodes. Not about objects.That’s my take on this.
@mediaprophet : What @timbl is saying is that he thinks and codes based on a realm comprising entities, entity types, entity relationships, and entity relationship types. He can even model for inferred entity relationship types (or even test their conceptual consistencies or inconsistencies) using N3 as a Rules Language.
For the rules part, you can also use SPARQL and terms from the SPIN or SHACL vocabs which enable it to function as a Rule Language too.
So the decision making boils down to using a language (or complimentary languages) that keep you rooted in a realm where entities are related to other entities in a variety of ways -- rather than being distracted by programming language symbols and the runtime objects they denote.
My rule of thumb: If you have to mention nodes, edges, and arcs in an attempt to describe an entity relationship type, the conversation is already completely broken, logically :)
@namedgraph_twitter regarding RDF-XML, the problem also became complicated by a combination of time and the general mindset around XML e.g., the notion that HTTP URIs didn't need to resolve which inadvertently lead to problems comprehending the utility of relative HTTP URIs that leverage "#" as an indexical.
In my experience, RDF-XML is a powerful notation for developing RDFizers (Transformers, Providers, Connectors) that emit 5-Star Linked Data.
Since 2007, we have developed close to 100 transformers for various APIs and Document Types using RDF-XML and XSLT. The key for us is keeping that in the box we call the Virtuoso Middleware Layer (a/k/a Sponger) i.e., users do not encounter RDF-XML at all, they simply enjoy the data wrangling and transformation benefits it provides :)
@namedgraph_twitter : All we can do (IMHO) is put our heads together and collaborate our way to a time and place where coherent use and understanding of what constitutes a Semantic Web permeates a majority of applications via the frameworks and libraries from which they are developed.
That would make things solid :)
@mediaprophet : To cut a long story short re. JSON-LD:
In its current form, it doesn't handle relative HTTP URIs properly.
Here's a lengthy thread that concludes with a fix to this particular JSON-LD bug -- that's part of the next release: json-ld/json-ld.org#488