[oslc-core] Discussion on vocabulary design

[Arthur Ryman]

Ian,

All vocabularies are not created equal. In the case of RDF, there is the 
notion of Upper Ontologies which are very general and intended to be 
extended by others. Creating a good Upper Ontology is a lot of work and 
probably not what we are trying to achieve at OSLC. I think we are trying 
to create data models for well-defined domains of software and systems 
engineering. I don't expect others to cherry pick useful predicates from 
our vocabularies and use them in other contexts, the way we are trying to 
use Dublin Core.

It is very important that OSLC specs do use other vocabularies when 
appropriate ones exists since that helps create a connected Web of data. 
Dublin Core and FOAF are good examples, however we do sometimes struggle 
to adapt  Dublin Core terms to our case, In some cases it may be clearer 
to coin a new predicate that has a well-defined meaning. Using Upper 
Ontologies is problematic for OSLC since doing so requires that we express 
the extensions using concepts from RDFS or OWL, which leads us into 
inferencing. That means in practice we have to invent stand-alone 
predicates.

I do agree that in general we shouldn't have to burn the exact range into 
the URI, however it may be appropriate in some cases to have more 
specialized predicates. For example, in genealogy having predicates for 
mother and father is handy even though a minimalist might be happy with 
just parent. However, not many would advocate parentMale and parentFemale.

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







From:
Ian Green1 <ian.green at uk.ibm.com>
To:
oslc-core at open-services.net
Date:
08/26/2010 07:06 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