Using the words subject, property and object might confuse some people

[lanthaler]

Using the words subject, property (note we aren't using predicate) and object might confuse some people. The subject has to be a JSON object, the (LD graph) object doesn't. We could mitigate that by talking about nodes which have properties whose values might be other nodes or a literal value.

[msporny]

There was a very conscious choice to not use the word "predicate"... it is not as commonly used as property to with native English speakers. It is a term that is a bit too technical, imho.

As for what we should change it to, maybe we could use the terminology in: http://json-ld.org/spec/ED/json-ld-syntax/20120122/#linked-data since we spent so long settling on something that would work for everybody. I'm a bit hesitant to make this change right now because I don't think it's been a large barrier. This is an editorial issue and I'm not as concerned about it right now.

Which part of the spec are you concerned about, specifically?

[lanthaler]

I agree, it's purely an editorial issue. The thing is that we use the same word (object) to denote different things which might make it difficult to understand for people. IMO the simplest solutions would be to drop the "RDF object" and generally speak more about nodes in a Linked Data graph. JSON-LD is not triple-centric, so that shouldn't be a problem...

A node has a number of properties whose values might be literals or other nodes.
A node is generally serialized as an JSON object and labeled with an IRI by setting its @id property.

[gkellogg]

If anything, we should make sure we align with RDF concepts, as that's feedback we've received consistently. RDF Concepts discusses nodes of an RDF graph being subjects and objects, so I think changing "RDF object" to node is consistent with that.

Interestingly, RDF Concepts uses property as one thing that a IRI can identify, whereas predicate refers to a position of such a URI in a triple. In that sense, property describes an abstract concept, so describing a key in a JSON object as a property is somewhat at odds with that, we could say that it identifies a property. However, this might be rocking the boat too much.

Similarly, a node in a graph represents a resource, which is named with either an IRI or a Blank Node (although a Blank Node does not actually identify a specific resource).

For my part, even though I came up with them, I've never been happy with subject definition and subject reference. We might be better using terms such as node description and node reference.

I'd like to see @cygri's thoughts on this, and this discussion should really take place on rdf-comments or rdf-wg, to the degree that we're discussion concepts and not pure editorial content.

(Hmm, looks like I'm about 7 months out of date on this one!)

[cygri]

I think that the decision to define a new data model for JSON-LD is unfortunate. It leads to a rather complicated multi-levelled terminological mess. Let me illustrate.

We have an “object” in a JSON document. This describes a “subject” in the JSON-LD graph. That's a “node” in the corresponding RDF graph. Which, in turn, refers to a “resource” in the domain of interest. (RDF graphs have “subjects” and “objects” too, but they are something different.)

An object in a JSON document may have name-value pairs. The “name” denotes a “property” in the JSON-LD graph. In the corresponding RDF graph, this “property” becomes a “triple”. This triple encodes a “statement” about the domain of interest. (And the domain of interest also has “properties”, but they are something different.)

Explaining any RDF syntax is already a difficult endeavour because there are three levels of terminology to deal with:

• the syntax level (e.g., “elements” and “attributes” and “tags” in RDF/XML, or “objects” and “arrays” and “name/value pairs” in JSON-LD)
• the data model level (RDF graph terminology, e.g., “triple” and “node” and “literal”)
• the domain level (the things being described by the graph, e.g., “resources”, “properties”, “classes”, “literal values”)

Adding a fourth level with new terminology to this picture doesn't help anyone, and only has the effect of guaranteeing that the terminology that will be used around JSON-LD will forever be a confused mess.

The argument I keep hearing from Manu for inventing a new data model is: “The existing data model is too complicated and most programmers wouldn't understand it.” I'm not convinced. The JSON-LD data model isn't significantly simpler than the RDF data model. The JSON-LD data model is also less precise (e.g., handling of unlabelled subjects, objects and properties; cardinalities of property-object pairs; identity of subjects and objects; can non-IRI objects be subjects too?). And it has a proper WTF moment when it distinguishes subjects and objects only to explain that objects can be subjects too. The whole affair doesn't seem any simpler than the existing RDF data model to me.

Of course JSON-LD, being a JSON syntax, needs to use vanilla JSON terminology such as “array”, “object”, “name-value pair”. IMHO there are three options for the additional terminology that JSON-LD needs to introduce:

1. explain JSON-LD as essentially an extension of the JSON data model (which consists of objects and arrays and values)
2. explain JSON-LD in terms of the RDF data model (nodes, predicates)
3. explain JSON-LD in terms of the domain-of-discourse terminology used in RDF (resources/entities, relationships, values, properties, classes)

The current choice, explaining JSON-LD in terms of a new from-scratch data model, is the worst possible choice.

[gkellogg]

On Aug 27, 2012, at 4:52 AM, Richard Cyganiak richard@cyganiak.de wrote:

On 27 Aug 2012, at 11:42, Andy Seaborne wrote:
I share your concern about the dangers of (what is perceived to be) a different data model. I'm not so sure that it is as bad as you paint it though.

Looking at:

http://www.w3.org/TR/json-ld-syntax/#linking-data

how would you change or tighten up the language in that section?

As I said in my email, I can see three reasonable approaches:

1. Conceptualise JSON-LD as an extension of JSON (that is, it allows identification and linking of JSON objects, and extends the JSON data model with some richer constructs. Vanilla JSON is a tree of JSON objects and JSON arrays. JSON-LD is a graph of JSON objects.)

I believe this is the general take we've taken on JSON-LD so far. The problems (IMO) have come when we need to cross over and talk about Linked Data issues.

1. Pick terms from RDF Concepts (that is, speak of “nodes” instead of “subjects and objects”, “literals” instead of “objects that are labelled with text”, “predicates” instead of “properties”)

Yes, I agree. talking about subjects and objects becomes pretty confusing. In the issue, I've suggested changing subject definition and subject reference to node definition and node reference, where a node is defined using a JSON object.

Getting into the difference between nodes, subjects, resources, properties and predicates is best left to RDF Concepts.

1. Describe JSON-LD in terms of the claims it makes about the universe: Subject and objects are “resources”/“entities”/“things”. JSON-LD expresses “relationships” between them; “properties” are types of relationships. Strings, numbers and so on are “values”.

Given the goals of JSON-LD, the first seems most reasonable as it explains the benefits of using JSON-LD over vanilla JSON in terms that the target audience should already be familiar with and relate to. Personally, I think that the second is cleanest, but I suppose it would go a bit against the JSON-LD design goal of pretending that it has nothing to do with RDF.

The doc does a reasonable job of saying "JSON Object" when it means a the concept from JSON - maybe there are some places it does not get the naming quite right (editorial).

Yes, the doc attempts to distinguish "JSON Object" and "object", but the target audience will be familiar with the term "object" in the vanilla JSON sense, so why go against the grain by re-defining "object" to mean something else? What's wrong with "node"?

Agreed, but I think we'll probably stick with JSON object to keep it distinct from the concept of object in the triple-positional sense.

EricP - You are noted in "Issue 2" as suggesting "that the definitions of subject and object, while being practical, are at odds with [RDF-CONCEPTS] use in their roles within a triple." Care to say more?

I guess EricP's concern is that in RDF Concepts, subjects and objects are positions in a triple. In the JSON-LD data model, subjects and objects are what RDF Concepts calls nodes. RDF Concepts doesn't distinguish between “subject nodes” and “object nodes”; there's just nodes. RDF Concepts does distinguish between IRIs, blank nodes, and literals, unlike JSON-LD.

JSON-LD does distinguish between IRIs, blank nodes and values (literals).

Personally, I have always found that the data model of RDF is not too complicated. The main issue is the total amount of technology a web developer has juggle rather than any specific technology.

When faced with the task of learning RDF, the Turtle-as-records clicks. URIs and prefix names can be a early confusion - JSON-LD does not change for the better or worse.

Uh, no. JSON-LD does change it for the worse. In Turtle, we have absolute URIs, relative URIs, and prefixed names. In JSON-LD, we have these three, plus term expansion. So there's four different ways of writing a URI.

RDFa also has terms, and terms are really necessary for people to work with JSON-LD as JSON.

The other confusion is "what is a graph?" A graph is a set of nodes and a set of edges. It can be drawn as a picture. An RDF graph does not include an explicit set of nodes - it's just the edge set. A node label can be an edge label. This is again the same in JSON-LD and RDF Concepts.

Unlike RDF, JSON-LD allows literals as subjects and predicates, allows multiple nodes with the same IRI, doesn't allow string literals that happen to contain an IRI, and allows multiple identical edges (i.e. is a multiset of triples).

Actually, JSON-LD does not allow literals as subjects. A subject is always identified by the @id key of a JSON object (or an unnamed BNode if it does not exist). The value of an @id key is always interpreted as an IRI or BNode. I think there was some mis-communication about this earlier.

Other RDF representations, also allow the same IRI to be used in multiple contexts as a subject. In fact, when JSON-LD is turned into RDF, these are merged together, much as they would be in RDFa or Turtle. Part of the framing algorithm (not in a REC-track document just yet) does include a flattening step, which reconciles multiple JSON objects containing the same @id into a single JSON object. We should probably move flattening, or something like it, into the API document.

JSON-LD also doesn't specify whether IRIs are absolute or relative, doesn't say what exactly an internationalized string is, doesn't say what range of datatypes are supported, doesn't say whether graphs can be merged or how, and doesn't say when two graphs are identical; so in all of these regards its data model might also differ from RDF.

I don't follow you on this. JSON-LD's use of IRIs is the same as Turtle or RDFa, for all practical purposes. Relative IRIs, not used as a property or type, are resolved relative to the document base.

As with JSON, strings come from UTF-8, with language identified using the @Languge key, either as part of an expanded value, or defined within a context. This is similar to the @lang definition within RDFa or RDF/XML. If there's some normative text you believe should be added to clarify this, I would be fine with that.

WRT graphs, JSON-LD provides a syntax for specifying them, pretty similar to the same way they can be specified in TriG. Notions of graph equivalence fall to the data model, not the serialization format, don't they? Given that this is a normative transformation from JSON-LD to RDF, graph equivalence and other semantics leverage RDF.

JSON-LD also contradicts itself regarding the possibility of unlabelled edges (not possible according to the definition, but possible according to a NOTE a bit later).

Yes, we could add something that prohibits a key in a JSON-LD object from having the form of a BNode; I don't think this would really loose anything. The grammar in A.1 should say:

Keys are IRIs, compact IRIs, terms defined within the active context which MUST evaluate to absolute IRIs, or one of the following keywords

or words to that effect.

I would support removing that note, but I think the original came as a result of lobbying by Glenn McDonnald

1. A predicate should be represented as a URI.

It should be possible to associate a predicate with an IRI, but I don't believe IRIs are very good as actual predicates, any more than they are as column-headings in a table, and even if you want to associate a predicate with an IRI, this is a model-level assertion that should be done once per type-arc, not once per instance assertion. And, in fact, I believe many, many data applications can function perfectly well without their arcs being formally meta-modeled at all.

This was to be inclusive of notions of Linked Data that aren't RDF, but I think it's probably appropriate now to close the loop on this and settle that a property MUST be labeled with an (absolute) IRI.

It seems to me, that out of this came the SHOULD description, and thus opened it to include BNodes, when the acutaly intention (I think) was to not require any binding at all. In fact, this can be done in JSON-LD, but properties (keys) that don't bind to absolute IRIs are discarded during expansion anyway.

So, I think we can clear this up by saying that a property MUST be an IRI, and consistent with the general principle of allowing non-conforming data in JSON-LD, any properties that don't resolve to absolute IRIs are discarded.

So I don't think it's the same data model. It's not just a difference in choice of words here and there.

(JSON-LD also contains a narrow definition of "Linked Data" that contradicts five years of existing W3C specifications, but that's another rant for another day.)

RDF is not an RDF format!

B.1, where this is asserted, should be stricken, or moved someplace else. We need to be clear that the concepts outlined in JSON-LD Syntax are based on, and fully consistent with RDF Concepts.

Right, and neither are B.4 Microformats nor B.5 Microdata.

As a syntax, Microformats can be turned into RDF, although not normatively. For this audience, both Microformats and Microdata are appropriate when discussing how they relate to JSON-LD.

Microdata is just as much of an RDF format as RDFa (like it or not): Microdata-RDF However, as with JSON-LD, microdata does not necessarily need to be transformed to RDF to be useful.

Gregg

[gkellogg]

More from @cygri:

Hi Gregg,

Thanks for the response. Comments inline.

On 27 Aug 2012, at 18:25, Gregg Kellogg wrote:

1. Conceptualise JSON-LD as an extension of JSON (that is, it allows identification and linking of JSON objects, and extends the JSON data model with some richer constructs. Vanilla JSON is a tree of JSON objects and JSON arrays. JSON-LD is a graph of JSON objects.)

I believe this is the general take we've taken on JSON-LD so far. The problems (IMO) have come when we need to cross over and talk about Linked Data issues.

I'm not sure I understand the distinction you draw between JSON-LD issues and Linked Data issues and where you need to cross over from one to the other.

1. Pick terms from RDF Concepts (that is, speak of “nodes” instead of “subjects and objects”, “literals” instead of “objects that are labelled with text”, “predicates” instead of “properties”)

Yes, I agree. talking about subjects and objects becomes pretty confusing. In the issue, I've suggested changing subject definition and subject reference to node definition and node reference, where a node is defined using a JSON object.

I think it would help if you stated somewhere very clearly: “In JSON-LD, every JSON object falls into one of X categories: node definition, node reference, …”

If you stop using the term “object” for the “nodes” of a JSON-LD graph, then I'd think that terms like “node object” and “reference object” instead of “node definition” and “node reference” might be better, because they're kinds of JSON objects.

Note: “subject definition” and “subject reference” are currently defined in a section that starts: “JSON [RFC4627] defines several terms which are used throughout this document: …” These terms are certainly not defined in RFC 4627!

Getting into the difference between nodes, subjects, resources, properties and predicates is best left to RDF Concepts.

Sounds reasonable.

1. Describe JSON-LD in terms of the claims it makes about the universe: Subject and objects are “resources”/“entities”/“things”. JSON-LD expresses “relationships” between them; “properties” are types of relationships. Strings, numbers and so on are “values”.

Given the goals of JSON-LD, the first seems most reasonable as it explains the benefits of using JSON-LD over vanilla JSON in terms that the target audience should already be familiar with and relate to. Personally, I think that the second is cleanest, but I suppose it would go a bit against the JSON-LD design goal of pretending that it has nothing to do with RDF.

The doc does a reasonable job of saying "JSON Object" when it means a the concept from JSON - maybe there are some places it does not get the naming quite right (editorial).

Yes, the doc attempts to distinguish "JSON Object" and "object", but the target audience will be familiar with the term "object" in the vanilla JSON sense, so why go against the grain by re-defining "object" to mean something else? What's wrong with "node"?

Agreed, but I think we'll probably stick with JSON object to keep it distinct from the concept of object in the triple-positional sense.

+1

EricP - You are noted in "Issue 2" as suggesting "that the definitions of subject and object, while being practical, are at odds with [RDF-CONCEPTS] use in their roles within a triple." Care to say more?

I guess EricP's concern is that in RDF Concepts, subjects and objects are positions in a triple. In the JSON-LD data model, subjects and objects are what RDF Concepts calls nodes. RDF Concepts doesn't distinguish between “subject nodes” and “object nodes”; there's just nodes. RDF Concepts does distinguish between IRIs, blank nodes, and literals, unlike JSON-LD.

JSON-LD does distinguish between IRIs, blank nodes and values (literals).

I'm referring to the definition of the JSON-LD data model in the ED:
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#linking-data

In RDF Concepts, there are three kinds of nodes: IRIs, blank nodes, and literals.

In the JSON-LD model, IRIs are not kinds of nodes (kinds of subjects/objects), but labels on a node.

Blank nodes are not mentioned; it is merely mentioned that nodes can be unlabelled. (To be fair, that's probably close enough.)

Literals are not mentioned.

“Data values” are mentioned as a possible label on a node, besides IRIs and text. So it certainly doesn't match the RDF Concepts notion of literals or literal values.

Note that RDF Concepts, nodes are IRIs or literals; they are not labelled with an IRI or literal. But I guess I can live with a phrasing that says that nodes are labelled with IRIs or labelled with a literal or unlabelled, if it's done consistently.

Personally, I have always found that the data model of RDF is not too complicated. The main issue is the total amount of technology a web developer has juggle rather than any specific technology.

When faced with the task of learning RDF, the Turtle-as-records clicks. URIs and prefix names can be a early confusion - JSON-LD does not change for the better or worse.

Uh, no. JSON-LD does change it for the worse. In Turtle, we have absolute URIs, relative URIs, and prefixed names. In JSON-LD, we have these three, plus term expansion. So there's four different ways of writing a URI.

RDFa also has terms, and terms are really necessary for people to work with JSON-LD as JSON.

I was disputing the claim that IRI handling in JSON-LD is as simple as in Turtle, that is all.

The other confusion is "what is a graph?" A graph is a set of nodes and a set of edges. It can be drawn as a picture. An RDF graph does not include an explicit set of nodes - it's just the edge set. A node label can be an edge label. This is again the same in JSON-LD and RDF Concepts.

Unlike RDF, JSON-LD allows literals as subjects and predicates, allows multiple nodes with the same IRI, doesn't allow string literals that happen to contain an IRI, and allows multiple identical edges (i.e. is a multiset of triples).

Actually, JSON-LD does not allow literals as subjects.

Well…:

[[
• An object may be labeled with an IRI or a label that is not an IRI such as plain text, internationalized text, or a strictly-typed data value.
• A node may be a subject and an object at the same time.
]]
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#linking-data

There is nothing in the definitions that rules out literals as subjects. As an implementer, given the definitions above, I'd certainly assume that they need to be supported.

A subject is always identified by the @id key of a JSON object (or an unnamed BNode if it does not exist). The value of an @id key is always interpreted as an IRI or BNode. I think there was some mis-communication about this earlier.

How is an implementer supposed to know that between all the mechanisms of the language, there is no way to generate a literal in subject position, if the data model allows it?

Other RDF representations, also allow the same IRI to be used in multiple contexts as a subject. In fact, when JSON-LD is turned into RDF, these are merged together, much as they would be in RDFa or Turtle.

Well, but RDF is really specific about the fact that the graph node is an IRI, and hence if parsing produces the same node in multiple places, then it actually is the same node.

In JSON-LD, as far as I can tell, we end up with multiple nodes that are labelled with the same IRI, right?

Or, to ask it a different way: If you were to visualize the “linked data graph” represented in a JSON-LD document that has multiple subject definitions with the same @id, would there be one or multiple nodes in the graph?

Part of the framing algorithm (not in a REC-track document just yet) does include a flattening step, which reconciles multiple JSON objects containing the same @id into a single JSON object. We should probably move flattening, or something like it, into the API document.

JSON-LD also doesn't specify whether IRIs are absolute or relative, doesn't say what exactly an internationalized string is, doesn't say what range of datatypes are supported, doesn't say whether graphs can be merged or how, and doesn't say when two graphs are identical; so in all of these regards its data model might also differ from RDF.

I don't follow you on this. JSON-LD's use of IRIs is the same as Turtle or RDFa, for all practical purposes.

JSON-LD defines IRIs as:

[[
• A subject should be labeled with an IRI (an Internationalized Resource Identifier as described in [RFC3987]).
]]
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#linking-data

RFC 3987 defines both absolute and relative forms.

Turtle and RDFa both defer to RDF Concepts, which explicitly states that IRIs are always absolute.

Relative IRIs, not used as a property or type, are resolved relative to the document base.

Well, I wouldn't know that from reading the JSON-LD data model definition.

As with JSON, strings come from UTF-8, with language identified using the @Languge key, either as part of an expanded value, or defined within a context. This is similar to the @lang definition within RDFa or RDF/XML. If there's some normative text you believe should be added to clarify this, I would be fine with that.

Again, here's what the data model definition says about internationalized text:

[[
An object may be labeled with an IRI or a label that is not an IRI such as plain text, internationalized text, or a strictly-typed data value.
]]
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#linking-data

Is there guidance somewhere that tells implementers what information they need to store to represent an internationalized string? For example, does one need to store the string's character encoding? If not, how would an implementer know?

WRT graphs, JSON-LD provides a syntax for specifying them, pretty similar to the same way they can be specified in TriG. Notions of graph equivalence fall to the data model, not the serialization format, don't they?

Sure, but the JSON-LD data model doesn't say anything about graph equivalence.

As far as I understand, the normative data model of JSON-LD is what you call “Linked Data”, and define here:
http://dvcs.w3.org/hg/json-ld/raw-file/default/spec/latest/json-ld-syntax/index.html#linking-data

Given that this is a normative transformation from JSON-LD to RDF, graph equivalence and other semantics leverage RDF.

I don't see how an optional conversion algorithm that converts JSON-LD into a different data model, presented in a different specification, can be taken as answering questions about the JSON-LD data model.

JSON-LD also contradicts itself regarding the possibility of unlabelled edges (not possible according to the definition, but possible according to a NOTE a bit later).

Yes, we could add something that prohibits a key in a JSON-LD object from having the form of a BNode; I don't think this would really loose anything.

(I'm not saying that all edges should be labelled. I'm just pointing out the inconsistency.)

The grammar in A.1 should say:

[[[
Keys are IRIs, compact IRIs, terms defined within the active context which MUST evaluate to absolute IRIs, or one of the following keywords
]]]

or words to that effect.

I would support removing that note, but I think the original came as a result of lobbying by Kingsley

[[[
A property SHOULD be labeled with an IRI.
]]]

(from requirements: [1])

This was to be inclusive of notions of Linked Data that aren't RDF, but I think it's probably appropriate now to close the loop on this and settle that a property MUST be labeled with an (absolute) IRI.

(FWIW, I'm not opposed to allowing simple keywords as properties, and resolving them against some sort of base IRI in order to form absolute IRIs during RDF conversion. There are certainly benefits to such a design in terms of lowering barriers to entry, cf. microdata.)

So I don't think it's the same data model. It's not just a difference in choice of words here and there.

(JSON-LD also contains a narrow definition of "Linked Data" that contradicts five years of existing W3C specifications, but that's another rant for another day.)

RDF is not an RDF format!

B.1, where this is asserted, should be stricken, or moved someplace else. We need to be clear that the concepts outlined in JSON-LD Syntax are based on, and fully consistent with RDF Concepts.

FWIW, my main concern is that the data model section (3.1) should be aligned to RDF Concepts as far as possible, and should use the same terminology. This doesn't mean that the definitions all need to be the same. If it makes sense for the JSON-LD use cases to deviate from RDF definitions (e.g., allow unlabelled edges, or restrict the available literal datatypes, or whatever), then JSON-LD should just use the same term with a different definition. It is then easy to systematically list the differences in an Appendix.

My other concern is that the definitions should be really precise, as they are in the JSON spec and (hopefully) in RDF Concepts. I mean, from reading just the data model definition, I should be able to implement a JSON-LD graph store that stores instances of this data model, right? I shouldn't need to go through the syntax spec with a magnifying glass to discover all the details of what's allowed, included and excluded in the data model.

(Finally, but that's again another rant for another day: Once the data model is really clear, I think that JSON-LD should really be introduced by listing all the ways how its data model differs from the JSON data model. So, all the things it adds above vanilla JSON. Arbitrary graphs instead of trees. Hyperlinks within and across documents. I18n and arbitrary data types. Expansion of keys into globally unique IRIs. I think this is really important. If you cannot explain to a JSON developer why they should care about these additions over plain JSON, then you get the RDF/XML problem where people try to produce the stuff with XML goggles on without understanding at all what's going on.)

Right, and neither are B.4 Microformats nor B.5 Microdata.

As a syntax, Microformats can be turned into RDF, although not normatively.

That is true, and I've implemented a collection of microformat-to-RDF parsers for Sindice. This doesn't change the fact that microformats are not RDF formats.

For this audience, both Microformats and Microdata are appropriate when discussing how they relate to JSON-LD.

Sure, but the heading of Appendix B is still wrong!

Microdata is just as much of an RDF format as RDFa (like it or not): [2]

Well, there is a difference between a W3C REC and a W3C IG Note. That's besides the point here though.

However, as with JSON-LD, microdata does not necessarily need to be transformed to RDF to be useful.

But again, microdata is not an RDF format and cannot be sensible listed under a heading “Relationship to other RDF formats”.

Best,
Richard

[lanthaler]

RESOLVED: "subject definition" renamed to "node definition", "subject reference" renamed to "node reference"

[lanthaler]

_@gkellogg reply to @cygri's latest mail:_

Hi Richard,

We spent considerable time discussing these issues on today's JSON-LD teleconference. We did create some resolutions to help clarify maters, and have a general agreement to try to bring terminology together with RDF Concepts. Some of the data model differences require further discussion and need to be publicly aired, as they impinge on long-held resolutions in JSON-LD.

In order close the gap between the use of subjects and objects vs nodes, we agreed to change "subject description" to "node description", and "subject reference" to "node reference".

It will also be clarified that node descriptions may be partial, and that the abstract node is formed from the union of all node descriptions within the document (actually within a specifically identified graph in a document).

The "flatten" algorithm will be moved from the framing document into the API document, so that there is a normative mechanism for resolving node descriptions with a common subject into a single mode description; note that this is already accomplished when transforming to RDF.

The notion of "property" in JSON-LD is a syntactic convention, used to refer to the "name" (or key) position in a node definition when that is used to define an edge in the linked data graph. In the abstract model, this is equivalent to an RDF predicate.

We will make clear that JSON syntactic elements fall into either node descriptions, node references literal values, or arrays of such values. (There are some special cases, such as language maps, which are discussed in the grammar section).

One proposal requiring further discussion would be to simplify the Linked Data definition within the syntax document [2] to something along the following lines:

1. Linked Data is a set of documents, each containing a representation of a linked data graph.
2. A linked data graph is an unordered labeled directed graph
3. A node having an outgoing edge MUST be an IRI or Blank Node.
4. A node having an incoming edge MUST be an IRI, Blank Node or value such as a number or a string.
5. A node MAY have both incoming and outgoing edges.
6. An edge MUST be an absolute IRI. (note: property is a syntactic term, edge is abstract)
7. Two nodes related by an edge form a statement where the nodes are referred to subject and object and the edge referred to as the predicate. (At Risk, we may not need to talk about subjects, predicates or objects at all).
8. IRIs used within a linked data graph SHOULD be dereferenceable to a Linked Data document describing the resource denoted by that IRI.

The fact that a JSON-LD document is a valid JSON document, and may contain properties and values that do not expand as required of a JSON-LD document allows subjects which are strings and properties which are not absolute IRIs to be represented, even though they will be dropped when using the JSON-LD API.

Also note that the toRDF API method is normative and not optional. Of course, a consumer may choose not to perform the transformation just as a consumer may choose to work with RDF/XML as just XML.