I still think it is a bad practice to embed in predicate names any assumption of the type of resource on either end, however I accept this as a compromise :-)
With that said, I think this kind of advice is exactly what "guidance" is all about. Pointing the reader in the right direction. <jim/> jim conallen CAM Lead Architect [email protected] Rational Software, IBM Software Group From: Dave <[email protected]> To: oslc-core <[email protected]> Date: 08/31/2010 09:31 AM Subject: Re: [oslc-core] Addition to Link Guidance: don't make assumptions about links Sent by: [email protected] Confirming: this change has been made in the link guidance. Thanks! - Dave On Mon, Aug 30, 2010 at 9:28 AM, Dave <[email protected]> wrote: > +1 to Steve's revision. Thanks Steve (and Ian and Jim too). > > Unless I hear reasoned opposition today, I'll change to Steve's version. > > Thanks, > - Dave > > > > On Mon, Aug 30, 2010 at 8:56 AM, Scott Bosworth <[email protected]> wrote: >> +1 on Steve's modified language.. In particular, I found the language in the >> original about "bad practices on property names" to be inappropriate for >> general guidance on links ...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 08/29/2010 01:14:53 PM: >> >>> From: Steve K Speicher/Raleigh/IBM@IBMUS >> >>> To: oslc-core <[email protected]> >>> Date: 08/29/2010 01:15 PM >>> Subject: Re: [oslc-core] Addition to Link Guidance: don't make >>> assumptions about links >>> Sent by: [email protected] >>> >>> After first and second read, I proposed this modified version of the >>> guidance. I still think there are scenarios where putting "kind" of >>> relationship in the name is valid, but the guidance should state >>> that even if it is named this way the actual type of the target may >>> not be an expected one. >>> >>> Updated guidance: >>> >>> Don't make assumptions about the target of links >>> >>> Relationships in OSLC resources are at their simplest an RDF >>> property whose object is a URI. Some properties require and assume a >>> resource of a particular type as the target for a given link type. >>> In general however, it is desired not to make type assumptions on >>> the target of links. The property's purpose and name should clearly >>> reflect the scenarios it is supporting. Since the usage of these >>> relationship properties may exist for a long period of time, >>> specification authors should use great care in determining these. >>> >>> As resources evolve over time, and they adapt to different >>> situations, different types will be exposed as targets to existing >>> link types. Well behaved clients should gracefully handle resource >>> types it doesn't expect when exercising links in resources. >>> >>> Thanks, >>> Steve Speicher | IBM Rational Software | (919) 254-0645 >>> >>> >>> > From: Dave <[email protected]> >>> > To: oslc-core <[email protected]> >>> > Date: 08/27/2010 01:48 PM >>> > Subject: [oslc-core] Addition to Link Guidance: don't make >>> > assumptions about links >>> > Sent by: [email protected] >>> > >>> > Jim Conallen and Ian Green wrote the guidance below on links and I've >>> > added it to the Link Guidance document for your review. I think it >>> > offers good advice and stops short of making mandates, which is also >>> > good. Thoughts? >>> > >>> > Thanks, >>> > Dave >>> > >>> > >>> > The new guidance: >>> > >>> > Don't make assumptions about the target of links >>> > >>> > Relationships in OSLC resources are at their simplest an RDF property >>> > whose object is a URI. Some properties require and assume a resource >>> > of a particular type as the target for a given link type. In general >>> > however, it is considered a good design not to make type assumptions >>> > on the target of links. It is also considered a bad practice to embed >>> > in the predicate name assumptions of the resource type of the object. >>> > For example the link type oslc:implementedByChangeRequest implies the >>> > target resource is a Change Request. Instead the preferred type would >>> > be oslc:implementedBy. >>> > >>> > As resources evolve over time, and they adapt to different situations, >>> > different types will be exposed as targets to existing link types. >>> > Well behaved clients should gracefully handle resource types it >>> > doesn't expect when exercising links in resources. >>> > >>> > Link: >>> > http://open-services.net/bin/view/Main/ >>> > OSLCCoreLinksDRAFT#Don_t_make_assumptions_about_the >>> > >>> > _______________________________________________ >>> > Oslc-Core mailing list >>> > [email protected] >>> > http://open-services.net/mailman/listinfo/oslc-core_open-services.net> >>> _______________________________________________ >>> Oslc-Core mailing list >>> [email protected] >>> http://open-services.net/mailman/listinfo/oslc-core_open-services.net >> >> _______________________________________________ >> Oslc-Core mailing list >> [email protected] >> http://open-services.net/mailman/listinfo/oslc-core_open-services.net >> >> > _______________________________________________ Oslc-Core mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-core_open-services.net
