Linked data: next frontier for the service-oriented enterprise

Linked data: next frontier for the service-oriented enterprise

Summary: Service oriented architecture and XML address transactional services, but enterprises still need a way to manage, digest and share information to complement these services.


Loraine Lawson just pointed to an interesting analysis of what's next in the drive toward a service-oriented, always-on, connected enterprise. Data is the extremely valuable commodity that the business needs to manage, digest and share, but the challenge of data integration hasn't been fully resolved by XML, Web services or service oriented architecture.

The paper, co-authored by a team led by Philipp Frischmuth and Jakub Klímek and posted on the Semantic Web Journal site, observes that classic SOA implementations to date have focused on transaction processing, but organizations seeking to being together their disparate data silos need to move on to the next step: "linked data."  As they explain, the rise of ERP, CRM and an abundance of systems enterprises now rely on call for a new approach:

"Classic SOA architectures may be well-suited for transaction processing, however more efficient technologies are available today that can be employed for enterprise data integration. In particular, the use of the linked data paradigm for integrating enterprise data appears to be a very promising approach."

So what is the "linked data paradigm"? According to Wikipedia, linked data "describes a method of publishing structured data so that it can be interlinked and become more useful. It builds upon standard Web technologies such as HTTP and URIs, but rather than using them to serve web pages for human readers, it extends them to share information in a way that can be read automatically by computers. This enables data from different sources to be connected and queried." Tim Berners-Lee, director of the World Wide Web Consortium, originally coined the term, the entry adds.

Within enterprise, linked data is manifested through what the authors call "enterprise knowledge intranets" or, alternatively, an "enterprise data web" that complements SOA and assorted intranets. This linked data layer on top of databases addresses the data lifecycle and management issues for the enterprise and for all its systems, including extraction, storage, querying and linking. Essentially, the authors are calling for a service-oriented data services layer that can feed any and all applications and users.

Such a strategy is not without challenges. Query and system performance is a top concern. And, as always, there are the organizational challenges, especially when it comes to showing return on investment. "For example, it is relatively easy to determine the return-on-investment for an integration of two information systems, while it is very difficult to precisely assess the cost savings of the Linked Data approach," the authors caution.

"Also, the added value of the Linked Data approach might only become visible after a critical mass of Linked Data interfaces and resources are already established in the enterprise."  Sounds identical to the issues involved when starting up SOA-based service repositories, and data warehousing for that matter. The initial projects may cost a lot more up front, but the value is realized as it becomes cheaper and cheaper to set up interfaces to the data services, rather then reinventing the wheel for each application.

The eventual payoffs include development of an enterprise knowledge base that facilitates interlinking and annotating content in enterprise wikis, content management systems and portals; as well as establishing a stable set of reusable concepts and identifiers. Loraine puts it in perspective: "It sounds almost like a some sort of virtual intergalactic Starbase for data, with all the data ships coming in to be updated and integrated with all the other data hubs," she observes, adding that progress reaching this ideal state may be slow. "We may be trying Linked Data integration while on an actual Starbase."

(Photo by Joe McKendrick.)

Topics: Data Centers, CXO, Enterprise Software, Software

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • RDBMS does all this already

    The "links" are defined in relations (tables or views in SQL speak) and explicitly define how different classes relate to each other.

    So do your database design properly and you don't really need all this "architecture".
  • Linked data enable semantic queries and reasoning

    one of the keys in linked-data is that all the relationships are explicit (not implicit like in relational database systems). this enables semantic queries and reasoning.

    lets look at an example:

    a database contains tables about artists, artworks, galleries, gallery events and cities. if i turn these data into linked-data the query and reasoning engine can answer a query like "Exhibitions in NYC Next Week with Modern Paintings between 5000 and 10000 USD"

    since the relationships are explicit in the data the reasoner (semantic engine) can "walk" the data and automatically (without SQL coding) find the precise answer (dynamic cross referencing). linked-data also natively support things like synonyms (e.g. NYC stands for New York City) and subclassing (e.g. Abstract Paintings are a subcategory of Modern Paintings).

    since Linked-Data follow a data co-existing approach vs. a data merging approach queries like this can also be executed across different databases without having to create an overall schema.

    all arguments which justify Linked-Data as an extremly valuable technology on top of a relational database system (or many relational databases)


    bernard angerer
    • The relational model is based directly on predicate logic

      and can therefore do exactly the kind of reasoning you describe.

      I seriously doubt whether the system you describe can do "semantic reasoning" as this would imply the system actually "understood" the relation between the symbol in the system and the actual object in the real world. Like an RDBMS it would just be doing symbol manipulation, but (hopefully) manipulation based on defined premises and consistent rules.

      Of course you have to name all the attributes (or columns as they are called in SQL) in the database consistently for this to work well, but the same goes for "linked data".

      You can then dispense with the need for the "linked data" altogether. One less level reduces complexity and less unnecessary complexity leads to more reliable and understandable systems.

      I would see sub-classing as a very restrictive approach to data design as necessarily you want to relate different attributes to potentially many different other attributes. So a painting by Picasso might be both abstract and modern, but also classified as cubist. Not all cubist paintings are abstract however.

      In a relational database these relations are absolutely explicit because the relation between them is defined in relations (tables or views in SQL speak); that's why it is called a relational database management system.
  • relational databases where never designed for reasoning


    i see you replied to my comment...

    the first thing i feel someone should look at is that Linked-Data follow the object oriented approach... and this is a quite different approach then the table oriented approach from relational databases.

    about the relations:

    when Linked-Data people talk about explicit relations (vs. implicit ones)... what they mean is that in the Linked-Data world every object contains properties which are direct and "typed" links (meaning they contain information as to what the relationship is about) to other objects. the links must (!) be defined in this way. in relational database systems
    the reality is that in many cases the knowledge about what relates to what is (hard)coded into the middleware.

    a consistent way how the data model deals with relationships is essential for a reasoner to work. the field of semantic reasoning on top of Linked-Data or "Graphs" is nothing new... please see

    Linked-Data where never designed to replace databases but the opposite... to add essential capabilities on top and across relational databases.

    i hope this makes sense...


    bernard angerer
    • The graph "model"

      Has been tried, and abandoned as unworkable, with CODASYL over 20 years ago.

      I see no point in trying to revive it.