I've been looking at OWL in order to understand if the approach we are taking in the core wrt to Resource Shapes is aligned with industry trends. My findings are mainly positive, but there are a few places where we might consider closer alignment.
First some background on OWL. OWL lets you describe resources. It's like RDF Schema, but has some notable differences, the main one being that in RDF Schema you cannot express constraints on the structure of resources. In OWL you can and therefore we could use OWL to describe OSLC resources. OWL itself is a family of three increasing expressive languages called OWL Lite, OWL DL, and OWL Full. You can trade off expressibility for computability. OWL Full is similar to RDF Schema. OWL Lite and OWL DL are restricted in order to achieve desirable computational characteristics, For example, in OWL DL many questions are decidable, i.e. there are alogithms that terminate in a finite time. This is not the case for OWL Full. The main difference bewteen OWL DL and OWL Full is that in OWL DL, there is a strict classification of resources into Classes, Properties, and Individuals. Also, Properties are further classified as either Object Properties or Datatype Properties. The value of an Object Property is an Individual. The value of a Datatype Property is a literal value. OWL Lite has some further technical restrictions. As an exercise, I created OWL definitions of all the OSLC resources, e.g. ServiceProvider, QueryCapability, etc. I found that most of these can be expressed in OWL DL, which is a good thing. However, we go outside OWL DL when it comes to ResourceShape and Property. This is not surprising since ResourceShape and Property are actually metamodelling resources. For those interested, here is my initial draft of an OWL version of OSLC Core. Conclusion: Resource Shapes are more expressive than OWL DL and may therefore be less tractable computationally. We could get back into the OWL DL zone by doing two things: 1. Use OWL DL instead of defining our own ResourceShape and Property resources. We will still have to keep some our the properties we defined in order to express things not covered by OWL, e.g. the notion of a read-only property. I believe we can add these as so-called annotation properties on the corresponding OWL resource. 2. Restrict the type of resources defined by OSLC domains to be describable in OWL DL. The main change here is restricting the properties to be either Object or Datatype Properties. As it stands, an OSLC Resource Shape allows properties whose values can be either URI refs or literal values. Do we really need this flexibility? There are some other technical restrictions in OWL DL. The only way to be confident that OWL DL is a good fit is to describe some OSLC Domains. I am planning to do this for EMS 1.0. Regards, ___________________________________________________________________________ Arthur Ryman, PhD, DE Chief Architect, Project and Portfolio Management IBM Software, Rational Markham, ON, Canada | Office: 905-413-3077, Cell: 416-939-5063 Twitter | Facebook | YouTube
oslc.owl
Description: Binary data
