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 <[email protected]> To: [email protected] Date: 08/26/2010 07:06 AM Subject: [oslc-core] Discussion on vocabulary design Sent by: [email protected] 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 [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
