Developing Semantic-Web-friendly specifications

Posted on by

This serves a personal position statement for the CETIS Future of Interoperability Standards Meeting 2010-01-12

Why and how the Semantic Web

We want interoperability specifications and standards with a Semantic Web underlay,

  • because that is
    • the fundamental common denominator,
    • well-adapted to evolving systems,
    • good for reuse,
    • post-modern;
  • using and enabling a “linked data” strategy, with emphasis on:
    • URI-identified resources,
      • with types of resource that are widely agreed for a domain;
    • links between them,
      • using common DC-like relationships/properties/predicates;
  • but with no immediate need for RDF all at once…
    • for RDF, think more Turtle than RDF/XML;
    • any XML should be RDF friendly:
      • able to be clearly mapped and transformed to triples;
      • there may be blank nodes
        • which may be filled in one day;
    • can approach RDF via RDFa and/or GRDDL approaches;
    • may not need XML, as long what there is can be transformed to RDF;
  • using the DCMI Abstract Model as a reference point.

Where a community of practice exists

Where there is good existing practice with electronic tools, experience suggests that it is effective to start with an informal, community-driven specification initiative, and the community in question would be in the best position to decide if and when to offer the specification to a formal body for standardisation. Such an initiative could:

  • start from existing data;
  • inclusively unify current good practice.

This unification would involve:

  • establishing common conceptual models as groundwork (see below);
  • identifing elements that are close enough, and merging them;
  • retaining elements that are likely to be used in more than one system.

Good qualities for a target specification include:

  • the appropriate reuse of existing RDF-friendly specs;
  • ease of implementation;
  • graceful degradation for lesser-used features;
  • being able to be repurposed and reused in the same way that it reuses other specs.

Common conceptual models

Where there is as yet insufficient practice to fuel a specification effort by a community of practice, it is useful to get together as many people as are interested, from formal and informal groupings, and:

  • seek first to agree on a clear common conceptual model  where everyone’s point of view is represented, filling out hidden, elided concepts,
    • recognising that this involves all in development, as
    • it is a challenge to loosen up a conceptual scheme, so
    • people need support and the right context.

Such a conceptual modelling process can work well by being primed with personal discussions between those able to develop their conceptual models. It is essential to the viability of a common conceptual model that everyone with a significant variant opinion is drawn in to the process of working towards a common model. Each of these discussions needs to focus on mutual understanding and a mutual development of positions so that each position comes to include a partial model that is shared between the parties. This takes time – typically several hours, not a few minutes – but is very promising.

This deep communication and shared modelling process is certainly not well-adapted to formal committee procedure. Nor is it suitable for a collective process of a community of interest or of practice. But both formal and informal bodies can perfectly well encourage dialogues of this kind to happen, and seek to check whether they have in fact taken place sufficiently to provide the basis of a usable common model.

Clearly, some people find loosening their conceptual structures more difficult than others. Bodies, formal and informal, should ideally stress that this is necessary, provide encouragement (and perhaps even education or training) in how to do it, and finally discourage those who are unable or unwilling to do this from participating in these processes at all.

Information models, specifications and standards

After the agreement of a common conceptual model, information models can be based on it, as the basis for specifications and eventually standards. This does not mean that the whole conceptual model needs to be represented in any information model, nor even that complete parts of the conceptual model need to be. If no relevant information attaches to a particular concept in the conceptual model, it is quite reasonable to leave it out from a practical information model (resulting in what I have termed “elision”) as long as the conceptual model is kept in mind to refer back to.

Derivative information models should, rather:

  • feel comfortable to practitioners;
  • not be hard to implement;
  • but still be interoperable.

Notes and references

3 thoughts on “Developing Semantic-Web-friendly specifications”

  1. “Why and how the Semantic Web”
    o well-adapted to evolving systems,
    o good for reuse,
    These TWO are the best answer for me why Semantic Web.

    Reply

  2. Pingback: Friend or FOAF: The Building Blocks of Content and Identity Federation | Researchity – Idea for a Research Community

  3. The challenges for the Semantic Web are vastness, vagueness, uncertainty, inconsistency, and deceit. With Inconsistency/Interoperability being an very important one, an automated reasoning systems will have to deal with all of these issues in order to deliver on the promise of the Semantic Web.

    Reply