+1 on the new language Steve. I assume this would generally apply to most of our link type properties, including the relationship properties listed in domain tables as well as things like dcterms:contributor which can be the url of any resource (though may be a foaf;person). It would not apply to cases where we are requiring a specific type of resource at the url endpoint (in which case, anything else would be deemed to be incorrect -- e.g. oslc:serviceProvider property must refer to an oslc service provider document)...Scott
Scott Bosworth | IBM Rational CTO Team | [email protected] | 919.486.2197 (w) | 919.244.3387(m) | 919.254.5271(f) [email protected] wrote on 09/24/2010 01:58:50 PM: > From: Steve K Speicher/Raleigh/IBM@IBMUS > To: [email protected] > Cc: [email protected] > Date: 09/24/2010 01:59 PM > Subject: [oslc-cm] Proposed language / modifications to "Range" definition > Sent by: [email protected] > > Last core meeting I took an action to propose some changes to domain > specifications on how "Range" should be used for relationship properties > that were not "closed". Where not "closed" implies that other kinds of > resources could potentially live at the other end of the URI reference. > The need was to make sure that consumers knew that the intent of the > relationship was to loosely coupled and open, therefore encouraging > clients to be flexible in handling the de-refencing of these relationship > URIs. > > Here is a sample of the change for the CM spec [1] and the > relatedChangeRequest relationship property: > > New proposed changes:: > Range: any > Description: This relationship is loosely coupled and has no > specific meaning. The value of this property MAY refer to another > oslc_cm:ChangeRequest resource. > > Original: > Range: oslc_cm:ChangeRequest > Description: This relationship is loosely coupled and has no > specific meaning. > > Note: I made the change in the spec [1] for only the one property > > Looking for feedback on this proposed change. > > [1] http://open-services.net/bin/view/Main/CmSpecificationV2 > > Thanks, > Steve Speicher | IBM Rational Software | (919) 254-0645 > > > _______________________________________________ > Oslc-Cm mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-cm_open-services.net
