[oslc-core] Addition to Link Guidance: don't make assumptions about links

James Conallen jconallen at us.ibm.com
Tue Aug 31 10:06:14 EDT 2010


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
jconallen at us.ibm.com
Rational Software, IBM Software Group





From:       Dave <snoopdave at gmail.com>
To:         oslc-core <oslc-core at open-services.net>
Date:       08/31/2010 09:31 AM
Subject:    Re: [oslc-core] Addition to Link Guidance: don't make
            assumptions about links
Sent by:    oslc-core-bounces at open-services.net



Confirming: this change has been made in the link guidance.

Thanks!
- Dave


On Mon, Aug 30, 2010 at 9:28 AM, Dave <snoopdave at gmail.com> 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 <bosworth at us.ibm.com>
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 | bosworth at us.ibm.com |
>> 919.486.2197(w) | 919.244.3387(m) | 919.254.5271(f)
>>
>> oslc-core-bounces at open-services.net wrote on 08/29/2010 01:14:53 PM:
>>
>>> From: Steve K Speicher/Raleigh/IBM at IBMUS
>>
>>> To: oslc-core <oslc-core at open-services.net>
>>> Date: 08/29/2010 01:15 PM
>>> Subject: Re: [oslc-core] Addition to Link Guidance: don't make
>>> assumptions about links
>>> Sent by: oslc-core-bounces at open-services.net
>>>
>>> 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 <snoopdave at gmail.com>
>>> > To: oslc-core <oslc-core at open-services.net>
>>> > Date: 08/27/2010 01:48 PM
>>> > Subject: [oslc-core] Addition to Link Guidance: don't make
>>> > assumptions about links
>>> > Sent by: oslc-core-bounces at open-services.net
>>> >
>>> > 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
>>> > Oslc-Core at open-services.net
>>> >
http://open-services.net/mailman/listinfo/oslc-core_open-services.net>
>>> _______________________________________________
>>> Oslc-Core mailing list
>>> Oslc-Core at open-services.net
>>> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>>
>> _______________________________________________
>> Oslc-Core mailing list
>> Oslc-Core at open-services.net
>> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>>
>>
>

_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100831/e7551b9b/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100831/e7551b9b/attachment.gif>


More information about the Oslc-Core mailing list