Re: Designing a Linked Data developer experience

As part of a discussion about some technical points in JSON-LD, Hadley Beeman offered some comments from the TAG that seem to me to be relevant to this question:

https://github.com/w3ctag/design-reviews/issues/312#issuecomment-434689623

An excerpt:

> Where you are embedding it into HTML, JSON-LD is a valuable data store format for a lot of different use cases. We think it could be the default data format for the web – if it was exposed to the DOM (when embedded in HTML).
> To that end, we would like to define a JavaScript API for those script elements, to reflect that content back out to DOM.
> Now that we have JavaScript modules... it would be useful to define the static export of a JSON-LD processor, for use as a module. @travisleithead has been working on an HTML modules proposal. We should make it possible to identify the module typing of all of our resource types: imaging, types, scripts, CSS, etc. -- and it would be ideal to include JSON-LD in that list, and treat it like we treat all of our other resources. We should bring this in from the cold; it's too important not to use with the rest of the Web.

---
A. Soroka
Office of Research Computing : Office of the CIO : the Smithsonian Institution

> On Dec 30, 2018, at 3:09 AM, Austin Wright <aaa@bzfx.net> wrote:
> 
> 
> 
>> On Dec 29, 2018, at 02:09, Richard Light <richard@light.demon.co.uk> wrote:
>> 
>> On 28/12/2018 16:20, Ruben Verborgh (UGent-imec) wrote:
>>> Dear all,
>>> 
>>> The thread on easier RDF on this mailing list was/is probably the discussion of the year.
>>> 
>>> Another perspective on this topic is “how can we make Linked Data easy for non-RDF people?”
>>> Or perhaps: “do developers need to know RDF to build Linked Data applications?”
>>> 
>>> While Semantic Web technologies have been successful in several specialized areas,
>>> we still don’t have end-user applications that directly use Linked Data from the Web.
>>> We’ve often referred to it as our chicken-and-egg problem,
>>> and even though there’s a lot of data online, we’re not seeing a lot of consumer apps.
>>> 
>>> In my latest blog post [1], I am arguing that we haven’t sufficiently focused
>>> on front-end developers, who are the ones building apps for end users.
>>> Such front-end developers are very hesitant to start working with RDF or even “easy RDF”.
>>> Rather, they want integration with existing languages, frameworks, and tools they are using.
>>> And whether we like it or not, those include JavaScript, React, GraphQL, and the likes.
>>> 
>>> This led me to the question of whether we can design a developer experience for Linked Data
>>> without needing to expose RDF and its complexities, with a couple of concrete suggestions
>>> and lessons learned.
>>> 
>>> Your feedback is most welcome.
>>> 
>> Ruben,
>> 
>> Brilliant work: thank you.
>> 
>> On a less cutting-edge, but maybe more generic, level, I wonder why there is (AFAIK) no W3C 'GOM' (Graph Object Model) for RDF. The existence of the Recommendations for DOM and XPath has led to the implementation of support for these abstract models in most web UI development frameworks.  If completion of work on DOM had been followed by development of a GOM in say 2005, I suspect that the subsequent story would have been quite different.
>> 
>> A quick search turns up the Property Graph and API community group [1], which was founded in 2013 but then seems to have lost interest in itself.  Its blurb mentions "we need to bear in mind that there are several Property Graph vendors and implementations and we may not want to deviate significantly from current practice".  Is that the problem?
>> 
> 
> You may have to elaborate what you mean by ‘GOM’. I distinguish between the object model, and the API that exposes access to it. (Specifications appear inconsistent in their usage, the DOM spec calls itself simply “DOM”, but HTML points out out there’s DOMs that are not serializable as valid application/xhtml+xml or text/html documents).
> 
> So in this sense, RDF *is* the object model, encoded by concrete serializations like Turtle, RDF/XML, etc. (The same way the DOM is an object model that can be encoded by XML, HTML, EXI, etc).
> 
> There’s plenty of RDF APIs, including rdflib.js, and one built into the ancient Mozilla suite (and used until recently in Firefox). There’s less of a need for standardization of an RDF API because exchange of RDF data happens over concrete media types like Turtle; how that syntax gets parsed and processed is an unimportant black box.
> 
> The reason we have a DOM API is to have a standard way to expose the browser’s DOM to scripts. The browser doesn’t have any RDF data to expose, so there’s not been any need for an API to expose it with.
> 
> But perhaps hypermedia agents like browsers should do more with RDF data. Modern hypermedia user agents that I’m researching will require a standardized RDF API to expose RDF data to scripting. And there’s still a need for modularization, which demands a well-defined interface between modules. These modules can use the same API.
> 
> And we have had some specifications to this effect. As early as 2012 we had the RDFa API <https://www.w3.org/TR/rdfa-api/>, for example.
> 
> I do think there’s an important need for tooling and libraries. But I think the use case differs in small but significant ways from the DOM API.
> 
> We should look closely at use-cases for an RDF API… are they similar to the use cases for the DOM API?
> 
> Thanks,
> 
> Austin.
> 
> 
>> Thanks,
>> 
>> Richard
>> [1] https://www.w3.org/community/propertygraphs/
>>> Best,
>>> 
>>> Ruben
>>> 
>>> [1] 
>>> https://ruben.verborgh.org/blog/2018/12/28/designing-a-linked-data-developer-experience/
>> -- 
>> Richard Light
>

Received on Sunday, 30 December 2018 12:42:12 UTC