Re: Fwd: RDF/JSON

On 2 May 2013 04:52, David Booth <david@dbooth.org> wrote:

> On 05/01/2013 09:23 AM, Kingsley Idehen wrote:
>
>> On 4/30/13 7:21 PM, Peter Ansell wrote:
>>
>>>
>>> I am amazed that the JSON-LD developers feel threatened enough by
>>> RDF/JSON to be putting up a fuss about it possibly being a recognised
>>> format by the W3C. If True Web developers prefer JSON-LD then they can
>>> start off by using that once it gets out their, but it shouldn't stop
>>> the standardisation of Yet Another RDF Format just because it can be
>>> parsed using the same family of parsers.
>>>
>> RDF/JSON and JSON-LD should be given equal billing by the W3C. Picking
>> winners is a shortcut to politically induced inertia, every time.
>>
>>>
>>> Luckily RDF/JSON is already complete enough (and simple to understand
>>> for people wanting to work with RDF triples) that it can be useful for
>>> groups of developers whether the W3C decides to push it through or not.
>>>
>>
>> Yes, but the W3C should apply the "wisdom of Solomon" here by not
>> picking winners.
>>
>
> I disagree.  The explicit goal of standardization is to pick a winner --
> to *reduce* the choices -- because fragmentation is harmful to the
> community.
>
>
Fragmentation is not likely to be an issue if there are enough community
members who are able to transparently support multiple RDF file formats for
a common base model simultaneously. RDF is designed to have a single
abstract model that everyone can agree on, and it is practically, and
successfully, implemented by the RDF community using Content Negotiation
with the consistent use of the HTTP 406 and 415 headers. JSON-LD is
reaching out to an audience (True Web Developers) who have not been able to
agree on a common abstract model so far, so they rely on the literal JSON
file syntax (and its direct literal mapping to JSON objects and arrays and
keys and values in memory) as their base. That forces them to encode
semantics using the structure of their files, rather than encoding
semantics using an abstract model that is separately defined.

The big question is that by standardising JSON-LD to evangelise to
JSON-based Web Developers, is there either going to be any effect at all to
the RDF community, who will still successfully communicate Linked Data
using a range of RDF formats, or will JSON-based Web Developers actually
want to encode consistent relations between entities that appear in
different traditional Web APIs and even take it up on their side as being
semantically meaningful and contribute back useful RDF data to the existing
Linked Data web.

Fragmentation is also reduced by the use of distinct content-types for
JSON-LD and RDF/JSON so that there is no need to guess about what may be
inside of a given JSON-based-RDF-document that you find.

If two JSON-based RDF serialization standards served significantly
> different use cases then it would make sense to have both, and the
> differences should be publicized so that users can figure out which to use
> when.  But AFAICT the use cases for RDF/JSON and JSON-LD overlap
> *substantially*: both can be used for serializing both RDF that follows the
> Linked Data conventions and RDF that does not.
>
>
The use case for RDF/JSON overlaps with the use case for one of the
profiles of JSON-LD (flattened/normalised--where a consumer can render the
document to a JSON object in memory and immediately be able to execute a
single path-based query on the object to determine whether it contains a
particular RDF triple), so technically it could be a subset. Given that,
RDF/JSON would be a subset, and I wouldn't mind supporting it as one of my
supported file formats, if either all of the profiles were mandatory or the
flattened profile was mandatory as a minimum for document interchange with
every JSON-LD endpoint. The fact that to support JSON-LD properly you need
to understand and specifically support both upstream providers and
downstream consumers before rendering any RDF triples to documents makes it
distinct from RDF/JSON IMO, and I am by design not going to be compatible
with a given JSON-LD web service if I do not know before hand, and encode
into my application, what profile and what context URIs that particular web
service is expecting me to use when serialising my RDF triples.

I do *not* believe that there is a substantial difference in the way
> programmers want to access and manipulate RDF that follows the Linked Data
> conventions versus RDF that does not.  In one case the URIs are sometimes
> dereferenced; in the other they're not.  Big deal.  But there *is* a
> substantial difference between working with the data only at the syntactic
> (JSON) level, and working with it at the RDF triple level. That difference
> has *nothing* to do with Linked Data versus non-Linked Data.
>
>
The dereferencing of Linked Data URIs is not the main feature of JSON-LD in
my opinion. It is the ability to separate documents into common and
distinct parts, where the retrieval of the common data is not Linked Data
that one will be pointing to with RDF URIs for semantic purposes. The URIs
linking to contexts in JSON-LD are more Linked-Common-Interpretation-Data
that may reduce workloads and increases compactness in specific
JSON-LD-only Web Developer workflows. The massive risk that is entailed is
that these compact documents may not being processable to RDF in future if
the configuration data is no longer available, or the processor cannot get
out to the internet through a firewall, or the context changes in a
non-backwards compatible manner with previously published documents.

If Web Developers are never going to want to see RDF triples, they may
never bother to download the context documents either, as they can pick out
the necessary information from the document they have just parsed using
their JSON parser. That may cause a split in the JSON-LD community between
those who consume JSON-LD as JSON and those who consume it as RDF, as the
context can substantially change (or even lose triples if the context is
modified) RDF triples on a round-trip with or without using the context,
but it will not likely have a substantial effect on the JSON
interpretation.

By comparison, it may be similar to the way that it is not possible to
roundtrip every SPARQL Results set through the SPARQL Results CSV format,
as it was designed to be lossy to support a particular use-case. In that
case it was to support spreadsheet-based-consumers, where in the JSON-LD
case the potentially lossy element is to support JSON-based Web Developers
who do not have the requirement in their use case to provide safe-transit
for RDF triples through their applications. The alternative for SPARQL
Results is of course SPARQL Results TSV format which is not lossy, and for
JSON-LD it may end up being RDF/JSON which by design *always requires*
developers to encode all of the information in a single document so that
the community will always agree on that as its basis. As a consequence
there is no substantial difference for the RDF/JSON (and other similar RDF
Formats) community between those who consume it as JSON and those who
consume it as RDF, as even if triples are lost by an application, the
triples that exist are consistently interpretable without regard to
environmental conditions or support for a range of profiles.

Cheers,

Peter