Tuesday, August 13, 2013

OSLC Resource Models - pictures are worth a thousand words

Pardon the metaphor but seems quite accurate here that in order to scale, OSLC working groups (WGs) operate as near-independent groups.  These WGs all produced their piece of the overall picture of resources, their properties and relationships to other types of resources.  The resource models (sometimes referred to as data models) were driven based on a key set of integration scenarios and defined following guidance produced by the Core WG.  The Core WG itself even has various models to support a number of cases such as: describing service providers, resource shapes, discussions, and other commonly used terms.  With all these pieces often laying around in separate specifications (Wiki pages, vocabulary documents, etc) it can be quite helpful to pull these all together...especially using visualization of the resource models.
This first figure is an example of a diagram from the perspective of an OSLC Change Management Change Request definition.

I'll go into a bit more detail about this model a bit later.

In an attempt to simply view these resource models, I started with some work that Scott Rich had done, along with some approaches I had experimented with using Rational Software Architect (RSA)

To keep things very simple, I'll highlight some guidelines on how to develop this model in a UML modeling tool:

  • This is just a picture (for now), semantics are not clearly defined and they are not those of OO design.
  • All properties are modeled as an  'Attribute', they are just visualized in the diagram as an association (since property values/objects in RDF are nothing special).
  • Each domain, which has its own vocabulary document, is a separate package.  Also give each domain/package its own color
  • No special profile is used (I attempted to use OWL profile from OMG).
  • Even though there isn't an example restriction on the resource types (range) of properties, an explicit expected Class is still set.  A diagram with everything pointing to rdf:Resource wouldn't be too interesting.  Note to self: create a stereotype/visualization to make this obvious.
Ideally (and I know my modeling geek friends are going to like this) we can transform to/from some other descriptive form (OSLC Resource Shapes + RDFSchema).

The current model has been shared in the Eclipse Lyo project and additional examples are highlighted over on the OSLC Core wiki page.  I tucked the RSA model file into an Eclipse project titled org.eclipse.lyo.model which you can find in expected git location.  For those that use some tool other than RSA, I have also provided the .uml file.  I'd be interested to hear if anyone has another tool (and/or approach) to modeling these.  I'll try to advance in my spare time, including improving the diagrams.


  1. Very good initiative! The only overview of types and relations I have found so far is https://jazz.net/wiki/bin/view/Main/CALM2010LinkTypes - good to get an updated version and in lyo, not under jazz.

  2. Thanks for a great post, Steve.
    I like the idea!

    My questions are:
    * Is there always a bidirectional mapping between OSLC in RDF and OSLC represented as UML class diagram?
    * Are there patterns that cannot be mapped?
    * Can we write bidirectional transformations for that (for roundtrip engineering)?

    1. Thanks for the feedback.

      > Is there always a bidirectional mapping between OSLC in RDF and OSLC represented as UML class diagram?
      I haven't fully spec'd it out but I don't see what we can't define it. I have done XSD<->UML in years past. Just a matter putting some time into it.

      > Are there patterns that cannot be mapped?
      I think I hinted at some that we could just handle with stereotyping, like what are "typical" types for the attribute values.

      > Can we write bidirectional transformations for that (for roundtrip engineering)?
      Would be a good project for someone. I'm just doing some work in my free time. I know of some people looking to contribute some assets around OSLC resource shapes (SDK, test suite, ...) This would be helpful in converting from OSLC Resource Shapes -> UML and back.