Re: Official response to RDF-ISSUE-132: JSON-LD/RDF Alignment

Hi Markus,

A few details below, and then I'll propose a specific suggestion in a 
separate message . . .

On 06/08/2013 03:07 PM, Markus Lanthaler wrote:
> On Saturday, June 08, 2013 8:28 PM, David Booth wrote:
>> Uh . . . did you read that entire document?  Please do.  Because unless
>> one were intentionally exercising selective understanding, I do not see
>> how anyone could honestly misread it so badly as to not realize that it
>> is specifically talking about RDF and the Semantic Web, making
>> reference
>> to the way the HTML-based web works, and showing that the same
>> principles of linking and dereferencing are needed for RDF and the
>> Semantic Web.  The very first paragraph says:
>> [[
>> The Semantic Web isn't just about putting data on the web. It is about
>> making links, so that a person or machine can explore the web of data.
>> With linked data, when you have some of it, you can find other,
>> related,
>> data.
>> ]]
>> And the second paragraph explicitly says: "for data they links  between
>> arbitrary things described by RDF".  I don't know how he could have
>> said it more clearly.
> So maybe what he wanted to say after all was that people where using RDF
> incorrectly? :-P

Yes, there is a large element of truth in that, although "incorrectly" 
is too strong a word.  Some people were not taking full advantage of 
RDF, because they were not making their URIs dereferenceable.

>> Claiming that that document in any way supports the notion that Linked
>> Data is not based on RDF would be disingenuous to the point of being
>> fraudulent.
> I'm not saying that. I'm saying that it describes a generic concept. That
> concept can be realized with RDF. I think we just have to agree to disagree
> on this.

Then you're missing the whole point of that document.  The generic 
concept of linking information had existed for a long time.  Hypertext 
had been invented a long time ago, HTML had been used for years, and 
foreign keys had been used in databases for decades.  That document was 
not just describing the generic concept of linking information, it was 
*applying* that pre-existing concept to RDF for the Semantic Web -- 
telling people that these same principle needs to be applied to RDF -- 
and coining the term "Linked Data" for the result.

>>> Surprisingly exactly that "(RDF*, SPARQL)" remark was missing when
>> the term
>>> was coined.
>> Not surprising at all.  That document was clearly a rough draft.  It is
>> not surprising that TimBL added more clarification as he edited it.
> And apparently it still is. Just the few sentences you quoted are full of
> typos.
>>> We can continue forever to argue about whether it is needed or
>>> not. We can also argue whether it is possible to "provide useful
>>> information" by using an abstract data model, i.e., RDF. When you
>>> dereference a URI, you'll get back a representation which is in a
>> concrete
>>> syntax. So, it would be more correct to say
>>>     3) When someone looks up a URI, provide useful information,
>>>        using a standard format which can be interpreted as RDF
>>> Would that add any value given that you can interpret (convert) every
>> format
>>> to RDF? I doubt so. This group (myself included) is convinced that
>> doing so
>>> would scare of a large portion of the target group, i.e., average web
>>> developers.
>> That is your motive, and I have some sympathy for it.  But it does not
>> justify the attempt to re-define the meaning of such an important and
>> well-established term.
> We are certainly not re-defining it. If we are doing something, then we are
> generalizing it by omitting a remark.

But providing a new definition that omits that key element -- RDF -- 
*is* redefining it.

>> Claiming or implying that Linked Data is not based on RDF would be
>> misleading the public.  It is factually untrue.
> We are not claiming that Linked Data is not based on RDF. If so, please
> quote the relevant text from the spec. We are just not mentioning that
> Linked Data is based on RDF in the intro. That's it.

It is misleading by omission, because a critical element is omitted from 
the (re-)definition.  And apparently it is *intentional*, so as not to 
put off those who are allergic to the letters R D F.  Intentionally 
misleading readers about that term is *not* okay, regardless of the 
desire to avoid making it too scary for average web developers.

>> I do not believe that mentioning that Linked Data is "based on RDF"
>> will have a significant impact on the adoption of JSON-LD.
> Other people do; myself included based on first-hand experience.
>>> We just try to explain them the underlying principles in simple terms to
> get
>>> them interested and motivated enough to read the rest. The end of the
> spec
>>> makes JSON-LD's relationship to RDF crystal clear (IMO at least) and
>>> contains a whole lot of examples for people from the semantic web
> community
>>> already familiar with e.g. Turtle or RDFa. Those people don't need to
> read
>>> the introduction, they know the basics already.
>> I think it's good that it starts by explaining the underlying principles
>> in simple terms.  I do not believe that that objective will be harmed by
>> the three words "based on RDF".
> Well, I do. Other people do as well. So the compromise we settled on was to
> not mention it. We do not claim that Linked Data is *not* based on RDF, we
> neither claim that it is.

But the introduction currently contains an intentionally misleading 
definition of "Linked Data", and that is *not* okay.

Again, I do have sympathy for the idea of making JSON-LD as friendly as 
possible to average web developers, but intentionally misleading readers 
is *not* striking the right balance.

>>> The truth is that people strongly associate RDF with RDF/XML. In
>>> fact, it is difficult to have conversations without conflating RDF
>>> the data model and its serialization formats.
>> It would be nice if JSON-LD could help dispell that misconception.  But
>> to do so, people need to know that JSON-LD *is* a serialization of RDF.
> I see JSON-LD + as the gateway drug to the semantic web. People
> will found out that they are effectively already using RDF when they are
> ready for it. No need to scare them away at the first contact.

That's an excellent goal.

>>>> If the JSON-LD spec were to adopt a definition of "Linked Data" that
>>>> differs in such a critical way from the established meaning of this
>>>> term, it would be misleading the public and would create confusion
>>>> in the community.
>>> Sorry, but I just can't see how it is doing that.
>> Okay, to be very clear:
>> 1. Telling the public that Linked Data is not based on RDF would be
>> misleading the public, because Linked Data -- in the original and
>> well-established sense of the term -- very clearly *is* based on RDF.
> OK, we are not doing that.
>> 2. That would create confusion in the community because people would
>> then have differing notions of what is Linked Data.  Thus, when people
>> talk about Linked Data, there would be confusion about what is meant.
>> If the meaning is not kept clear, people may start claiming that
>> arbitrary JSON is "Linked Data", or that spreadsheets that contain some
>> URLs are "Linked Data", or that database tables that have foreign keys
>> are "Linked Data", or HTML pages of census data with links to other
>> pages are "Linked Data".
> I never believed, but apparently that Linked DataT Police really exists :-)
> So, why is it that people talk about Linked Data then instead of RDF?

People talk about Linked Data instead of RDF because: (a) the term 
"Linked Data" is more descriptive, easier to understand, and less 
off-putting than "RDF"; and (b) it specifically implies 
dereferenceability of URIs.

> If the
> difference really matters in a conversation, simply talk about Linked Data
> based on RDF or HyperRDF to avoid confusion.

That would be *creating* confusion rather than avoiding it: (a) by using 
multiple terms for the same concept; and (b) by implying that Linked 
Data can be based on something other than RDF.

> [...]
>>>>>> 2. Define a *normative* bi-directional mapping of a JSON profile to
>>>>>> and from the RDF abstract syntax, so that the JSON profile *is* a
>>>>>> serialization of RDF, and is fully grounded in the RDF data model and
>>>>>> semantics.
>>>>> We already do this here:
>>>> No, it doesn't.  That section explicitly says: "This section is
>>>> non-normative".
>>> JSON-LD consists of two specs, the syntax spec and the algorithms and API
>>> spec. The normative transformation to RDF can be found here:
>> It needs to be much clearer that the bi-directional mapping to/from the
>> RDF abstract syntax is normative.  As I said in my last email:
>> [[
>>   > In discussing this at SemTech with Gregg Kellogg -- BTW, thanks for
>>   > getting together Gregg! -- he told me that it is the working group's
>>   > intent that JSON-LD be a *normative* serialization of RDF.  So if
> that's
>>   > the case, it sounds like this may be an editorial issue: the document
>>   > needs to be much clearer about how the relationship is normative.  At
>>   > present, it is not at all clear that it is normative.  Maybe what's
>>   > needed would be something as simple as "This section is non-normative.
>>   > However, JSON-LD is a normative serialization of RDF: the normative
>>   > relationship between the JSON-LD syntax and the RDF model is defined in
>>   > section @@@@."
>> ]]
> So, would changing the introduction of section C.1 "Transformation from
> JSON-LD to RDF" to the following sentence address your concerns?
>     JSON-LD documents can be parsed as RDF and RDF data can be serialized
>     as JSON-LD. It is beyond the scope of this document to describe the
>     algorithms in there details, but a summary of the necessary operations
>     is provided to illustrate the process. The normative algorithms are
>     can be found in RDF Conversion Algorithms in the JSON-LD Processing
>     Algorithms and API specification [JSON-LD-API].

Close.  I'll suggest a slight modification in a separate message, so 
that we can separate this issue from the issue of re-defining "Linked Data".


Received on Sunday, 9 June 2013 21:27:26 UTC