What Are Linked Data Services?

continuing from my recent musings around the question of Linked Data Services (prompted by discussions in the context of the W3C Linked Data Platform Working Group), it seems that one question that's not quite as easy to answer as one might think is: What Are Linked Data Services? however, to build a platform, we have to think about what service that platform is providing, and what assumptions should or should not be built into it.

while this could be seen as a more general question of how to define and design Service Oriented Architecture (SOA) services, this post will frame the problem in terms of RDF and non-RDF scenarios, because that's the main missing part in today's linked data story (building bridges to non-linked-data-land). looking at recent SOA history, it's important to keep in mind that XML was not successful because of a widespread existence of XML-based components (few clients and servers ever used XML internally), and the same can be said for JSON. the important success factors of XML and JSON for SOA metamodels were the widespread availability of toolkits for handling these serializations, and the ease of processing and mapping them to whatever metamodels components use internally (that latter aspect is where JSON has scored better than XML in the recent past).

framing the world in a duality of RDF and non-RDF components, in a SOA scenario, we can easily distinguish three cases where RDF plays a role (and there is a fourth where it does not enter the picture).

1. RDF services accessed by RDF clients: this case is a homogeneous scenario where metamodels match, and is one where SOA approaches often may feel a little unnecessary. instead, the common approach is to let interactions use the shared metamodel assumption, and allow direct interaction, for examples based on SPARQL. security and privacy issues may still be an important consideration (not all data managed by services necessarily should be available to clients, and clients should have constraints for what they can submit/add to server-side data), but the approach of expressing interactions in a separate service model seems almost like overhead.
2. non-RDF services accessed by RDF clients: work in this area has been done in the linked data community, often in an attempt to design wrappers around non-RDF services that allow RDF clients to interact with them as if they were RDF services. because most of this work originates in the linked data community, the service model often is defined in RDF, thus using a metamodel that is easy to consume for RDF clients.
3. RDF services accessed by non-RDF clients: this scenario is what building bridges from linked data is all about; exposing the richness and possibilities of linked data to clients that do not natively speak RDF. the challenge in this case is to design a service surface that is not requiring for consumers to use RDF, while still exposing the value of the service. like all other SOA scenarios that involve some metamodel mismatch, there's a challenge how to deal with the mismatch, but also an opportunity to open services to a much bigger set of potential consumers.

in my previous life, focusing on XML as a SOA foundation, i wrote about "Model Mapping in XML-Oriented Environments". while this was assuming that clients were all agreeing on using XML as the metamodel of the service surface, today people might prefer JSON, or maybe even a choice of XML or JSON (but see JSON or XML: Just Decide for an overview of why such a dual approach has its own disadvantages). but the important observation remains: SOA designs need to focus on service surfaces, and ideally should neither make assumptions of shared models (except for the service model, which i often refer to as the service surface), or shared metamodels.

starting from this observation of avoiding tight coupling of SOA components, scenario 1 from the above list is almost an SOA anti-pattern when it would lead designers to make assumptions about shared models or metamodels of the components. such a design would introduce much more coupling than is acceptable in a SOA landscape.

looking at scenario 2, it actually looks quite a bit like what GRDDL does, and GRDDL probably approaches the problem in a useful way. the assumption there is that for the majority of clients, delivering services in non-RDF (in GRDDL's case the metamodel of choice is XHTML/XML) form, but also giving clients an easy way how to transform the service surface into their natively preferred format, RDF. the genius of GRDDL is that interactions still happen in the space of a well-defined hypermedia format (HTML), but there is a way how clients can get RDF views of the individual state representations they get from the non-RDF service.

scenario 3 is where the biggest value can be realized from the linked data point of view, because it allows the vast majority of potential consumers in the world (non-RDF consumers) to tap into the value produced by RDF producers. it also allows clients to easily combine RDF-based services with others, realizing even more value by mashing up a variety of services, independently of their internal foundations.

picking a SOA metamodel (both for the data model as well as for the interaction model) is an important decision, because it has many implications on how easily services can be used, re-used, and re-combined in often unforeseen ways. SOAP suffered mostly because of a very code-specific interaction model, and because SOAP implementations often were not very good, or simply not available. learning from SOAP's problems and REST's success, it can be seen that hypermedia-driven interaction models and widely support data models are a good foundation for designing and building loosely coupled services. for the linked data scenario, that means that picking established interaction and data models would be a good choice, and also will be a good fit to make scenario 3 from above, the one with the highest value, possible in an easily consumable way.

this blog post has been an attempt to clarify the question: What Are Linked Data Services? from a SOA perspective, the most promising answer is to say: they are linked-data-based services that build on established interaction and data models for service surfaces, and that provide loose coupling, so that the 1% of RDF-based components in the world (and that's probably a wildly exaggerated overestimation of their share) can provide their services to the 99% of non-RDF consumers. the primary goal of SOA is to unlock value that before has been limited to a narrower set of consumers, and to make it available to a set of consumers that is as wide as possible. linked data services probably don't need any new standards or technologies for this, or only very few, but they probably need design patterns and best practices so that their value can be delivered to a larger set of consumers. my guess is that feeds will play a role in this, and that some of the developments of the evolving atom landscape will turn out to be useful building blocks.

[[ ps: in a recent discussion about how to represent links in RDF, things were approached in a different way, looking at how RDF could be used as the service surface itself. while this is a possible approach as well, it would require much more effort, changing RDF's very foundations to transform it from a data model to a hypermedia format. the question is whether such a fundamental change of RDF would be worth the effort, given that there is a readily available set of established standards for service surfaces already. ]]

Comments

[Mike Kelly]

I'm confused. "Linked Data" is a very generic sounding name, but apparently it requires the use of RDF - is that correct?

[dret]

@mikekelly85, "linked data" sounds generic, but the community defines it to be RDF-only. http://dret.typepad.com/dretblog/2009/11/the-linked-data-police.html happened a while ago when i used the term more loosely in a paper we published, and since then, i have made the distinction between "linked data" (the RDF way of doing things) and "data that's linked" (the REST way of doing things). obviously, it would be really good to bridge these two worlds, which so far are separated, and this blog post is an attempt to look at how those bridges could be built, focusing on what's already out there as established technologies and architectures, and what's missing in the current disconnected landscape.

[Kidehen]

I don't know how you've arrived at the conclusion that Linked Data is RDF-only. It isn't. Conflating the concept of Linked Data and RDF is the fundamental flaw retrospectively inserted into TimBL's original Linked Data meme. This strange marketing anomaly remains the biggest obstacle to Linked Data comprehension and adoption.

You can give *things* names that resolve to descriptor documents (resources) via indirection without any RDF in the mix. Remember, RDF is about using IRIs for denoting (naming) *things*. It says or claims nothing about use of indirection (implicit or explicit) to identify documents (resources) that describe what denoted.

Linked Data is fundamentally about use of indirection to associate an entity (real-world or otherwise) with a resource that bears its description via resource content.

Links:

1. http://bit.ly/M7Rcka -- Web 3.0 Manifesto re. Structured Data

2. http://uriburner.com -- example of a Linked Data service that produces Linked Data from a plethora of data sources while also offering said data in a myriad of structured data formats constrained by the entity-attribute-value model enhanced via incorporation of de-referencable URI based hyperlinks.

[Aharth]

Hi,

we've published about Linked Data Services (LIDS) at ESWC 2011:

Sebastian Speiser, Andreas Harth. "Integrating Linked Data and Services with Linked Data Services". 8th Extended Semantic Web Conference (ESWC 2011), Heraklion, Greece. [1].

The basic idea is to pass parameters in the query part of the URI. LIDS then return RDF. As such, our LIDS look to the outside just like standard Linked Data resources.

LIDS also have descriptions using basic graph patterns. Similar kinds of descriptions of input and output and relation between input and output can be used in services interacting via POST (see [2] for an overview).

Best regards,
Andreas.

[1] http://people.aifb.kit.edu/aha/2012/sms/lids-eswc2011.pdf
[2] http://linkedservices.org/