continuing from my recent musings around the question of 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).
- 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.
- 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.
- RDF services accessed by non-RDF clients: this scenario is what
building bridgesfrom 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
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. ]]