- 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