Re: JSON-LD requirements

Glenn and Gregg- Thanks very much for engaging on this over a holiday
weekend. This is helping me sort through my own thinking prior to the
call tomorrow.

Since implementing the first JSON-LD specification from earlier in the
year and being subsequently put-off by the added complexity of the
second, I have come around to embracing Glenn's point about Linked
Data in JSON mostly being "a matter of mapping dataset-internal
identifiers ... to IRIs." In our work at Elsevier on bringing
proprietary XML data schemes into linked data representations, and in
the discussions about how to get library and cultural heritage data
into linked data during the LOD-LAM summit last month, this was and is
the central question. Once it is answered, mapping from arbitrary JSON
into data structures that can be easily interpreted as triples or
quads in an RDF model, and then (potentially) mapped into the RDF
serialization of one's choice is simple. What we should be looking for
is a standard way to do that.

I believe Kingsley's plea some weeks back for a JSON equivalent to
N-Triples reflects this stance; I think this is also why he makes the
comment on today's thread as to why JSON-RDF doesn't suffice, since
that is largely what it tries to accomplish, whereas JSON-LD in its
current incarnation attempts to go further in capturing various
resource-centric idioms of RDF/XML.

Let me try to put that another way: JSON-LD has been about writing
JSON with a set of conventions from RDF practice (e.g. use of CURIEs
in properties) that make it easy to process into triples; Linked Data
in JSON could be about adopting a set of conventions that make it easy
to extract triples from arbitrarily written JSON. Much of what exists
in the JSON-LD specification can be adapted to the latter (e.g.,
@context.) I am hoping that the discussion we are having today makes
it clearer how to phrase the goals of the Linked Data in JSON effort
to accomplish this. It seems to me from the thread that you guys are
close to being in violent agreement on the way to talk about these
issues.

Bradley P. Allen
http://bradleypallen.org



On Sun, Jul 3, 2011 at 6:45 PM, glenn mcdonald <glenn@furia.com> wrote:
>> 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

Received on Monday, 4 July 2011 02:19:25 UTC