[oslc-core] Provided guidance for adding relationship labels

Tue Aug 31 17:24:41 EDT 2010

+1 on Ian's language. We are in fact defining a property of the link. That
property, the link label, could have nothing whatsoever to do with the
object resource. I still think its useful to also offer some
suggestions/common practices on how the value of the link label might be
seeded with information from the object resource, however if we can't do so
in a way that avoids the interpretation Jim found, then maybe we can drop
that language....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/31/2010 04:09:17 PM:

> From: Ian Green1 <ian.green at uk.ibm.com>
> To: oslc-core at open-services.net
> Date: 08/31/2010 04:09 PM
> Subject: Re: [oslc-core] Provided guidance for adding relationship labels
> Sent by: oslc-core-bounces at open-services.net
>
> My understanding of the intent is that this is a property *on the link*
> and is not cached data from the object resource.  The anchor label is a
> property of the link, and *could have nothing whatsoever* to to with the
> object resource.  Other properties on the link (a la AM spec. are also
> admitted, however only dcterms:title is the only link property whose
> meaning is defined by CM V2.0).
>
> I agree with Jim that the present wording leaves room for an
> interpretation along the lines of cached data and I think we should
strive
> to prevent this interpretation.  It is important that the label is on the

> link, and is not in any way necessarily describing the object resource.
> OSLC collaborators (consumers & providers) must not (i'd write MUST NOT
if
> I could) treat that link property as a description of the object
resource.
>
> Something along these lines is what I was imagining:
>
> Change Management relationships to other resources are represented as
> properties whose values are the URI of the object or target resource.
When
> a Change Management relationship property is to be presented in a user
> interface, it may be helpful to provide an informative and useful textual

> label for that relationship instance.  (This in addition to the
> relationship property URI and the object resource URI, which are also
> candidates for presentation to a user.) To this end, OSLC providers MAY
> suppport a dcterms:title link property in Change Management resource
> representations, using the anchor approach outlined in the OSLC Core
Links
> Guidance.
>
>
> I've removed the reference to UI Preview - UI Preview is for resources,
> and these links are not resources.  If we bring link properties and UI
> Preview together, I suggest that be done elsewhere in some form of
> guidance. However, I would worry then that OSLC is straying too far into
> UX/UI guidelines.
>
> best wishes,
>     -ian
>
> ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> Chief Software Architect, Requirements Definition and Management
> IBM Rational
>
> oslc-core-bounces at open-services.net wrote on 31/08/2010 20:22:27:
>
> > [image removed]
> >
> > Re: [oslc-core] Provided guidance for adding relationship labels
> >
> > James Conallen
> >
> > to:
> >
> > Steve K Speicher
> >
> > 31/08/2010 20:26
> >
> > Sent by:
> >
> > oslc-core-bounces at open-services.net
> >
> > Cc:
> >
> > oslc-cm, oslc-core
> >
> > my 2c,
> >
> > I worry about guidance that that suggests that it is ok to
> > essentially cache information about a resource that is being
> > referenced (and managed by) on another server. If this is to be a
> > practice, what are the recommendations for ensuring that this
> > information remains in sync. Looking at the referenced example, what
> > happens if the owner of the resource 123 changes its title to
> > "Enhancement 123: Enable multi-root installs"? Will this have to be
> > manually updated? If not, does the system automatically update
> > properties of links whenever it detects them.
> >
> > While I do recognize this may be a way to save a GET call. I don't
> > think it represents a best practice.
> >
> > <jim/>
> >
> > jim conallen
> > CAM Lead Architect
> > jconallen at us.ibm.com
> > Rational Software, IBM Software Group
> >
> >
> >
> > [image removed] Steve K Speicher---08/31/2010 02:47:42 PM---I wanted
> > to call out some specification updates that was created for handling
> > of relationship label
> >
> > From: Steve K Speicher/Raleigh/IBM at IBMUS
> > To: oslc-cm at open-services.net
> > Cc: oslc-core at open-services.net
> > Date: 08/31/2010 02:47 PM
> > Subject: [oslc-core] Provided guidance for adding relationship labels
> > Sent by: oslc-core-bounces at open-services.net
> >
> >
> >
> > I wanted to call out some specification updates that was created for
> > handling of relationship labels on URI relationship properties.  Note
> the
> > support for this is optional but wanted to make sure this was done in a

> > uniform way across implementations.  Let me know if there are any
issues
>
> > with this.
> >
> > http://open-services.net/bin/view/Main/
> > CmSpecificationV2#Labels_for_Relationships
> >
> > Thanks,
> > Steve Speicher | IBM Rational Software | (919) 254-0645
> >
> >
> > _______________________________________________
> > 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
>
>
>
>
>
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20100831/66291301/attachment-0003.html>