RE: JSON-LD requirements

Maybe we just need to invent terms that don't come loaded. My point was that nodes may be externally addressable, and use URIs, or be internally addressable, possibly using identifiers to reference them from within the document. If it's linked data, and is externally addressable it MUST have a URI. If it is only internally addressable, then it effectively has the same semantics as a BNode.

 

"Blank Node" and "BNode" are so heavily loaded I assumed you meant them in the RDF sense, so yes, different words would be better. What about "relative" and "absolute" IRIs? That's the sense I mean: the nature of the identifier doesn't determine whether the data is "externally" addressable, as you can always convert a relative IRI to an absolute one by prefixing something. I still think it shouldn't be even a conceptual option to have a node without an identifier.

 

A possible solution for this blank node discussion could be to use a fragment identifier specifying the (JSON) path to the specific object/attribute in the JSON representation. E.g. #knows[0].address (just as a trivial example). That’s what fragments are for anyway.

 

 

9. An object is a node in a directed graph that may be a non-terminal or a terminal node.

10. An object which is a terminal node is called a literal.

11. A literal may include a datatype or have a language.

 

I think this node-or-literal thing is one of the big copouts in RDF (albeit a perfectly understandable one given its resource-description origins). Every logical piece of data in a dataset should be a typed node. The mapping of these typed nodes to human-readable symbols is a different level or dimension. It should be fundamentally impossible to say that the president of the US is the string "Barack Obama". Multiple-language support also belongs in this symbolic level, not the logical level, otherwise you get inane things like not even being able to count how many objects you have for a given subject and predicate because you have no way to tell how many of them are translations of each other. And datatypes belong in a data-model, not restated by every instance node (or, worse still, by every appearance of an "object literal").

 

Agreed. In the syntactic model (JSON) this can rely on structural elements of the language. In the logical (Linked Data) model, I don't see how these can be separated.

 

I think since we are working towards Linked Data in JSON we should leverage JSONs structural elements and as thus I really think we should stop concentrating on triples. Of course it will be still possible to deconstruct a node into triples to integrate it with RDF data, but that shouldn’t impede us to concentrate on JSON objects and arrays in the same way they are widely used already.