[oslc-core] Discussion on vocabulary design

[Steve K Speicher]

These are all good points, though the approach the CM working group took 
was based on the scenarios we had in hand.  The "type-in-name" is not a 
model where it is intended to implicitly define the range of possible 
resource types but to distinguish itself from all other similar 
relationships.  As you stated, if we took to the extreme we could simple 
just use <dcterms:relation> and be done.  Though this doesn't say much 
more than search for the subject resource for all predicates who have an 
object who's type is a URI.

There is a penalty for a consumer to have to determine what the type of a 
linked resource is in that it needs to make a network request for that 
resource, it needs to parse and hope it gets type information.  By having 
the meaning of the relationship articulated in its predicate, for example 
affectsTestCase, a consumer clearly understands what that relationship 
means without having to know anything about what is on the other end of 
that URI.  We hope it is something meaningful.  So clients have to be 
written to be robust enough to handle just about anything but we expect 
the range of that relationship to be what we defined in the spec.

For CM, the scenarios really were about  traceability relationships for 
simple reporting scenarios (a high performant data warehouse or cache 
wasn't available).  I agree, if there are no scenarios to support a 
predicate name that is long and restrictive, then it should not be used.

Thanks,
Steve Speicher | IBM Rational Software | (919) 254-0645


> From: Ian Green1 <ian.green at uk.ibm.com>
> To: oslc-core at open-services.net
> Date: 08/26/2010 06:19 AM
> Subject: [oslc-core] Discussion on vocabulary design
> Sent by: oslc-core-bounces at open-services.net
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net