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.

Perhaps it should say "an entity with one or more values." My concern about
> expressing ordering is that it is inherently a difficult thing to do in many
> storage systems, and assuming that multi-valued relationships MUST be
> ordered, is placing an unnecessary burden on systems where ordering is not
> necessarily important.
>

I think supporting ordered target lists is pretty basic, personally, but I
can see the argument for making this a SHOULD rather than a MUST. (But you
have a MUST NOT about this in the JSON section, of course.)

Yes, in JSON. In LD, [a predicate] SHOULD/MUST be a URI.
>
> I'm disagreeing with this LD premise.

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'm not sure which "these" you mean at the end there.

g