- From: Markus Lanthaler <markus.lanthaler@gmx.net>
- Date: Wed, 3 Jul 2013 19:21:33 +0200
- To: "'RDF WG'" <public-rdf-wg@w3.org>
On Wednesday, July 03, 2013 6:57 PM, Peter F. Patel-Schneider wrote: > I guess that somehow my messages are not being completely understood. Yeah, unfortunately I still doubt that I understand you completely. > The thrust of my technical comments is to do away with the parallel set of > definitions in the JSON-LD documents in favour of building on the definitions > in the RDF documents. > > Parallel sets of definitions are bad from just about every aspect one > can imagine. OK, so when we talk about a graph somewhere in the JSON-LD spec how do we define it? It's certainly not the same as an RDF graph. For some things, like "language-tagged string", we could of course reference RDF Concepts... but I don't see much value in providing just a diff to RDF Concepts. The goal was to make the spec as self-contained as possible without requiring them to read, e.g., RDF Concepts. The proposal you made in http://lists.w3.org/Archives/Public/public-rdf-wg/2013Jun/0126.html presume that the reader is already familiar with the RDF data model. I expect that for most readers that won't be the case. So, with that in mind, what would be the minimal changes to the Data Model section (http://json-ld.org/spec/latest/json-ld/#data-model) necessary to address your concerns? How would you e.g., change the following definitions: A graph is a labeled directed graph, i.e., a set of nodes connected by edges. Every edge has a direction associated with it and is labeled with an IRI or a blank node identifier. Within the JSON-LD syntax these edge labels are called properties. Whenever practical, an edge SHOULD be labeled with an IRI. A language-tagged string consists of a string and a non-empty language tag as defined by [BCP47]. The language tag MUST be well-formed according to section 2.2.9 Classes of Conformance of [BCP47]. Thanks, Markus -- Markus Lanthaler @markuslanthaler
Received on Wednesday, 3 July 2013 17:22:05 UTC