What Are Linked Data Services?

continuing from my recent musings around the question of Linked Data
Services<http://dret.typepad.com/dretblog/2012/06/linked-data-services.html>(prompted
by discussions in the context of the W3C
Linked Data Platform Working
Group<http://dret.typepad.com/dretblog/2012/05/linked-data-and-rest-a-match-made-in-w3c.html>),
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"<http://dret.net/netdret/publications#wil06m>.
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<http://www.mnot.net/blog/2012/04/13/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<http://www.w3.org/TR/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<http://dret.typepad.com/dretblog/2009/04/feeds-as-query-result-serializations.html>will
play a role in this, and that some of the developments of the evolving
atom
landscape <http://dret.typepad.com/dretblog/atom-landscape.html> will turn
out to be useful building blocks.

[[ ps: in a recent discussion about how to represent links in
RDF<https://gist.github.com/2927644>,
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. ]]

http://dret.typepad.com/dretblog/2012/07/what-are-linked-data-services.html

Nice to see the LDP WG getting into gear! :)