[oslc-core] Discussion on vocabulary design

[Ian Green1]

Hello

We briefly discussed predicate names and Range specifications on 
yesterday's call. 

Concern has been expressed in the past that OSLC is designing vocabularies 
/ specifications which require assumptions to be made about linked data, 
and which are specialized rather than generalized.

The dublin core vocabulary, which we use, has dcterms:creator.  It does 
not have "dcterms:creatorFOAFPerson" "dcterms:creatorFOAFAgent" and so on. 
 This would be a unwieldy vocabulary.  It would be difficult to maintain 
as new types of "person" were defined, would not be forwards compatible (a 
client that knew about creatorFOAFPerson would not deal with 
creatorFOAFRobot).  If that client also knew about contributorFOAFPerson 
etc. each new person type would induce two new predicates that the client 
would need to deal with - queries, UI, etc.

One reason these vocabularies scale is that they are loosely coupled and 
highly cohesive.  Do we think the same is true of OSLC vocabularies?

For example, a ChangeRequest implements a Requirement:

This is reflected in CM specification as follows (i'm eliding the 
namespaces):
        - the name of the predicate - implementedByChangeRequest
        - the Range specifier in the written specification - Requirement

And in the RM specification as follows:
        - the name of the predicate - implementedBy
        - the Range specifier - unspecified.

In the RM specification there is no suggestion/requirement that a 
Requirement be implemented by a ChangeRequest - the name of the predicate 
is enough to capture the notion of "implementation", but makes no other 
constraint or implication (to the human reader of the specification, and 
to consumers).  The Range is also unspecified. Whilst OSLC Core is silent 
on the meaning of the Range (at least I can't see it explained), there is 
a risk that clients will misbehave in the case that the object of a 
implementsRequirement link were something other than a Requirement.

But this is not just about writing robust clients - it is about designing 
an open resource model that is flexible, extensible, composable etc. 
Characteristics such as forwards compatibility are desirable.  For 
example, if we followed the "type-in-the-name" style a new predicate 
"implementsModel" would be needed to support a scenario in which a 
ChangeRequest could implement an AM resource. Clients interested in 
"implementation" relationships would have to be upgraded to know about 
implementsModel in addition to implementsRequirement.  There is a 
combinatorial problem here, since over time the number of relationships 
will grow, as will the number of resource types.

My inclination is to factor "implementsRequirement" these into 
"implements" and "type of thing - Requirement".  We already have each of 
these notions separately in our OSLC resource models - name of predicate 
and rdf:type. 

Another extreme is to consider all such relationships to be equal, and 
call them all say "relatedTo".  This would be be problematic for another 
reason - it does not say enough about the nature of the relationship.  In 
RDF we can't specialize a predicate - each edge on the graph has a fixed 
URI, so to give additional meaning we need to pick a different predicate - 
there is no way to factor "implements" into "related" and something else 
[1,2].

best wishes,
    -ian

[1] Link properties could be used to express this "specialization" of a 
predicate - but that is a specialization of an instance, not a 
specialization of the predicate.

[2] RDFS would be one way to express such relations between predicates, 
but I'm not suggesting that here.






Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU