[OSLC-RM] Link types
James Conallen
jconallen at us.ibm.com
Wed Oct 7 15:37:10 EDT 2009
Yes,
So if we can standardize how links are managed in OSLC as a whole (i.e. the
proposed RDF example works for me), and we must support bi-directional
links; that additional <backlink> element could be sufficient enough to
provide a known mechanism for removing bi-directional links (perform a
DELETE on the link resource URI gets rid of it, and likewise a DELETE on
the URI specified in the backlink gets rid of link in the other direction).
<jim/>
jim conallen
jconallen at us.ibm.com
Rational Software, IBM Software Group
|------------>
| From: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Torge Kummerow <torgato at gmx.de>) |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-rm at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|10/07/2009 03:24 PM |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|Re: [OSLC-RM] Link types |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Sent by: |
|------------>
>--------------------------------------------------------------------------------------------------------------------------------------------------|
|oslc-rm-bounces at open-services.net |
>--------------------------------------------------------------------------------------------------------------------------------------------------|
Yes, but to get rid of "dangling" links we would need some kind of
neutral (in respect to source and target) instance where they are saved,
or back links, as else there will be some inefficient queries necessary
to get rid of those links.
And if we have that we can as well implement bi-/undirected links with
minor effort, or at least prepare this for the a future version.
Torge
James Conallen schrieb:
> I'm all for simpler. If we think at the generic OSLC level that there
> are no such things as bi-directional links between resources, that would
> simplify a common linking mechanism, and we wouldn't need this back link
> idea. However if someone does really need a bi-directional link, and
> they try to mimic one I fear our simple mechanism will make it really
> difficult.
>
> From the Architecture Management point of view, I do not believe we
> have any truly compelling use case scenario that can only be satisfied
> by a bi-directional link. So if we want to put forth the proposal to
> explicitly not support bi-directional links I am all for it.
>
> To address another point you have here Paul, web users don't have a
> problem with broken links because for the most part a living, breathing,
> thinking human is the one that has to react to it. In our case I am
> worried about the dangling links that get used in the queries and other
> automation on that other server without ever realizing that it should no
> longer exist. For example a requirement is linked to a test case with a
> back link. This is intended to mean that the requirement is tested by
> the test case. The link from the test case side is deleted (the tester
> realizes that the test does not in fact cover this requirement), but the
> link that is managed in the RM server is not deleted. A report that run
> to find all requirements that don't have a test case linked to it will
> never find this requirement. Even a human reviewing the requirement
> won't know until they try to actually navigate this link manually.
>
> <jim/>
>
> jim conallen
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
>
> Inactive hide details for Paul McMahan---10/07/2009 11:21:50 AM---A
> higher level of specificity and extra bi-directional managePaul
> McMahan---10/07/2009 11:21:50 AM---A higher level of specificity and
> extra bi-directional management around links could be seen as a de
>
>
> From:
> Paul McMahan/Raleigh/IBM at IBMUS
>
> To:
> oslc-rm at open-services.net
>
> Date:
> 10/07/2009 11:21 AM
>
> Subject:
> Re: [OSLC-RM] Link types
>
> Sent by:
> oslc-rm-bounces at open-services.net
>
> ------------------------------------------------------------------------
>
>
>
> A higher level of specificity and extra bi-directional management around
> links could be seen as a departure from the "web", where links are
> (usually) un-typed, can point at practically any type of content, and can
> be left dangling when resources are deleted or moved. Maybe its worth
> making this departure in order to simplify the job of a service provider
> and build more functionality into the CALM integrations.
>
> But on the other hand users of the web probably don't see invalid links
as
> being unusual or problematic. In that case the onus would be left on the
> service provider to find and potentially remedy dangling/invalid links in
> its own content rather than rely a third party to act responsibly (i.e.
> according to an OSLC link specification). IMHO this is a normal mindset
> for web service and content providers -- all outgoing links are suspect.
I
> think its risky to make a decision which has such long term implications
> within our 1.0 time frame.
>
>
> Best wishes,
> Paul McMahan
> Rational Quality Management
> pmcmahan at us.ibm.com
>
>
>
>
> James
> Conallen/Philadel
> phia/IBM at IBMUS To
> Sent by: "Simon Wills"
> oslc-rm-bounces at o <simon.wills at integrate.biz>
> pen-services.net cc
> oslc-rm at open-services.net
> Subject
> 10/07/2009 10:19 Re: [OSLC-RM] Link types
> AM
>
>
>
>
>
>
>
>
>
> this document looks great, and i believe could be used in the OSLC AM
> specification equally as well (I'm the lead there).
>
> I want to make a suggestion that I think will be useful. Allow an
optional
> <oslc:backlink rdf:resource="http://amserver/links/link42
> </oslc:backlink" /> element(s) to be part of the link. This reference
will
> be used to unambiguously define the back link that may be managed by
> another server, making it easier to delete, should this link become
> deleted. The other option is to "hope" that it is possible to query the
> other server to find the back link.
>
> Additionally I'll suggest an addition to the REST API to provide a means
to
> get a list of the server's known/supported link types (i.e. link
> predicate). This service would be used by clients to populate the UI when
a
> user is creating a new link. Or would be used by someone creating queries
> for resources that are in part dependent on a link. This would be where
the
> oslc:LinkType resource mentioned as inevitable would be used.
> Implementations have the option of allowing the POST/PUT/DELETE of these
> link types, but are under no obligation to.
>
> If we just did this, I think it will remain generic, and useful for all
of
> the OSLC 1.0 specifications (that have not been completed).
>
> <jim/>
>
> jim conallen
> jconallen at us.ibm.com
> Rational Software, IBM Software Group
>
>
>
> (Embedded image moved to file: pic27215.gif)Inactive hide details for
> "Simon Wills" ---10/07/2009 09:55:13 AM---Hi"Simon Wills" ---10/07/2009
> 09:55:13 AM---Hi
>
> (Embedded image (Embedded image moved to file: pic05643.gif)
> moved to file: "Simon Wills" <simon.wills at integrate.biz>
> pic20377.gif)
> From:
>
> (Embedded image (Embedded image moved to file: pic07856.gif)
> moved to file: "Torge Kummerow" <torgato at gmx.de>
> pic22755.gif)
> To:
>
> (Embedded image (Embedded image moved to file: pic19437.gif)
> moved to file: oslc-rm at open-services.net
> pic15922.gif)
> Cc:
>
> (Embedded image (Embedded image moved to file: pic18683.gif)
> moved to file: 10/07/2009 09:55 AM
> pic26054.gif)
> Date:
>
> (Embedded image (Embedded image moved to file: pic26797.gif)
> moved to file: Re: [OSLC-RM] Link types
> pic01032.gif)
> Subject:
>
> (Embedded image (Embedded image moved to file: pic24770.gif)
> moved to file: oslc-rm-bounces at open-services.net
> pic13483.gif)
> Sent by:
>
>
>
>
>
>
> Hi
>
> At risk of being told that I don’t understand what I’m talking about ...
> how difficult can it be to achieve some basic alignment during v1.0?
>
> At its simplest, a link asserts a relationship between two artefacts. It
> doesn’t need to be more complicated than that. So, slightly adapting
Ian’s
> proposal in
http://open-services.net/bin/view/Main/RmLinkResourceDefinition
> , an example of a general-purpose OSLC link could be:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <rdf:RDF
> xmlns:oslc="http://open-services.net/xmlns/common/1.0/"
> xmlns:dc="http://purl.org/dc/terms/"
> xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
> <oslc:Link rdf:about="http://www.example.com/resources/links/link1">
> <rdf:subject rdf:resource="http://www.example.com/resources/requirement55
> "/>
> <rdf:object rdf:resource="http://www.example.com/resources/workitem24"/>
> <rdf:predicate rdf:resource="http://www.example.com/types/actionedBy"/>
> <dc:modified>7 October 2009</dc:modified>
> <dc:creator>Ian Green</dc:creator>
> </oslc:Link>
> </rdf:RDF>
>
> Note that this doesn’t rely on any domain specific namespaces, and
doesn’t
> make any presumptions about the nature of the source and target
artefacts.
> Ian’s definition assumes (and I would agree) that the only required
> properties are the rdf:subject, rdf:object and rdf:predicate (aka the
> source, target and link type). The link type could start out in v1.0 as
> being a simple label, but could (would need to) evolve in time to become
a
> reference to an oslc:LinkType resource.
>
> This general purpose link resource can be extended in a variety of ways
> without conflicting with its basic definition. Hence, for example, the AM
> resource link definition at
> http://open-services.net/bin/view/Main/AmResourceLinkV1 could be made
> compatible by changing oslc_am:link to oslc:Link, and by replacing domain
> specific oslc_am:source, oslc_am:target and dc:type properties with
> rdf:subject, rdf:object and rdf:predicate. Other differences (e.g.
> expanding dc:creator into a foaf:Person element, and adding truly
> domain-specific properties) don’t destabilise the essential uniformity
that
> we would achieve.
>
> Clearly, there would be more to do (agree method support, work out how we
> deal with link collections, and sort out factory resources), but this
seems
> to me to be more straightforward than many of the domain-specific issues
> that the individual working groups are dealing with. And it would provide
a
> basis from which to evolve (note – evolve) to a more sophisticated model
in
> the future, incorporating link type resources, the ability to constrain
> links between given artefacts to be of defined types, and so on.
>
> Or maybe I am being too ambitious.
>
> Best regards
>
> Simon
>
>
>
> -----Original Message-----
> From: oslc-rm-bounces at open-services.net [
> mailto:oslc-rm-bounces at open-services.net] On Behalf Of Torge Kummerow
> Sent: 07 October 2009 13:54
> To: oslc-rm at open-services.net
> Subject: Re: [OSLC-RM] Link types
>
> Well, if it should be part of V1.0 or not is not my decision to make,
> however I would say this is an inevitable future for LinkTypes. To be
> able to constrain them to a specific source and target element group.
>
> Especially if we introduce a catalog of LinkTypes this would act as a
> good filter, showing only matching Types. However I doubt that a
> granularity beyond the domain is of much use. But this depends on the
> number of distinguishable sub elements in each domain I guess.
>
> Torge.
>
>
> James Conallen schrieb:
> > I too think that we need to accept for the fact that now each group
will
> > have its own solution, (which are somewhat similar when you consider
the
> > potential). I also think that no matter what is done, clients will
have
> > to change in the future, so why not do something now to support the
> > essential use cases and get us all started.
> >
> > In your second point, you describe a potential property of a link type
> > definition. The ability for a specific link type to restrict what can
be
> > on either end based on the 'domain' of the resource, or maybe even the
> > specific type of resource. I worry about getting this aspect of link
> > definition right so early on. While I think a generic and flexible
link
> > management system can be defined for 1.0, I think this particular
aspect
> > of a link type's definition might not be necessary or 1.0.
> >
> > <jim/>
> >
> > jim conallen
> > jconallen at us.ibm.com
> > Rational Software, IBM Software Group
> >
> >
> >
> > Inactive hide details for Torge Kummerow ---10/07/2009 08:21:40
> > AM---Well, it can?t hurt, if each group is presenting a solutioTorge
> > Kummerow ---10/07/2009 08:21:40 AM---Well, it can?t hurt, if each
group
> > is presenting a solution it thinks is the best approach. The con
> >
> >
> > From:
> > Torge Kummerow <torgato at gmx.de>
> >
> > To:
> > oslc-rm at open-services.net
> >
> > Date:
> > 10/07/2009 08:21 AM
> >
> > Subject:
> > Re: [OSLC-RM] Link types
> >
> > Sent by:
> > oslc-rm-bounces at open-services.net
> >
> >
------------------------------------------------------------------------
> >
> >
> > ic
> > Well, it can?t hurt, if each group is presenting a solution it thinks
is
> > the best approach. The consolidation will have to take place IHMO and
> > then as lots of input for finding the best solution.
> >
> > I also think that not only the linking spec should be defined
globally,
> > but also the mechanism in doing so shouldn't care which objects are
> > being linked right now, only the LinkTypes should care. (An RM->RM
> > LinkType can?t link a QM object with an CM object for example)
> >
> > Greetings,
> > Torge
> >
> > James Conallen schrieb:
> > > I absolutely agree. A uniform linking approach is critical to cross
> > > domain collaboration.
> > >
> > > The problem is that most of the new OSLC workgroups are on the hook
to
> > > provide a 1.0 specification by the end of this calendar year. The
> > > governing philosophy of the OSLC has been to deliver small sets of
> > > specifications that provide value immediately, and that can be built
on
> > > later.
> > >
> > > With that said we can either skip any attempt to define how links
can
> be
> > > managed, since it will most likely change once things are
consolidated
> > > later (the OSLC is working on providing common specifications across
> all
> > > domains). Or we can provide something that is useable now, but will
> most
> > > likely have to be changed later.
> > >
> > > If we don't do anything now, the spec will be incomplete with
respect
> to
> > > the essential use cases, since it will require additional knowledge
of
> > > the implementing system to be able to manage links, and that is
> > > essentially another form of point-to-point integration that we see
> > > across the tools today. If we do specify either a flexible approach,
or
> > > just define a fixed set of what we consider common link types, then
> > > clients built to this spec will have to change (possibly losing
> > > functionality) when the later ones come out.
> > >
> > > <jim/>
> > >
> > > jim conallen
> > > jconallen at us.ibm.com
> > > Rational Software, IBM Software Group
> > >
> > >
> > >
> > > Inactive hide details for "Simon Wills" ---10/07/2009 07:47:09
> > > AM---Hi"Simon Wills" ---10/07/2009 07:47:09 AM---Hi
> > >
> > >
> > > From:
> > > "Simon Wills" <simon.wills at integrate.biz>
> > >
> > > To:
> > > "Ian Green1" <ian.green at uk.ibm.com>, James
> > Conallen/Philadelphia/IBM at IBMUS
> > >
> > > Cc:
> > > <oslc-rm at open-services.net>
> > >
> > > Date:
> > > 10/07/2009 07:47 AM
> > >
> > > Subject:
> > > RE: [OSLC-RM] Link types
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Hi
> > >
> > > I think that there are three distinct issues here, namely:
> > >
> > > a. Whether there is a need for a uniform approach to
> > > defining link-related resources across OSLC;
> > > b. Whether we attempt to define a minimal set of
> > > standardised link types;
> > > c. Assuming that we **do** adopt a uniform approach to
> > > linking across OSLC, how and when we do so.
> > >
> > > Of these points, deciding whether or not to implement a uniform
linking
> > > model is by far and away the most important. Standardising link
labels
> > > is a 'nice to have' that follows on from this first decision (this
was
> > > the main focus of the RM discussion document), but is something that
we
> > > can live without. And the last point is to do with implementation.
> > >
> > > Ben's interests (i.e. reporting) provide a good illustration of the
key
> > > issue. If I understand correctly, he wants to be able to generate
> > > reports about lifecycle artefacts, some of which may require him to
> > > traverse links between artefacts, without having to make allowances
for
> > > the domains in which those artefacts live. This seems to me to be
> > > entirely reasonable -- and reporting isn't the only domain for which
> > this
> > > expectation holds.
> > >
> > > OSLC stands for Open Services for Lifecycle Collaboration. Lifecycle
> > > collaboration requires that we leverage relationships between
lifecycle
> > > artefacts. If we don't tackle the issue of uniformity in the
handling
> > > of links, we risk ending up with a series of poorly connected domain
> > > islands, each with its own domain-specific linking paradigm. Surely
> > > there is a /prima facie/ case to recognise that links are the things
> > > that tie these domains together, and hence that the definition of
> > > link-related resources and their behaviour should be common across
all
> > > OSLC domains?
> > >
> > > Best regards
> > >
> > > Simon
> > >
> > > *From:* oslc-rm-bounces at open-services.net
> > > [mailto:oslc-rm-bounces at open-services.net] *On Behalf Of *Ian
Green1*
> > > Sent:* 07 October 2009 11:39*
> > > To:* James Conallen*
> > > Cc:* oslc-rm at open-services.net*
> > > Subject:* Re: [OSLC-RM] Link types
> > >
> > >
> > > Hello Jim,
> > >
> > > I think your description of how OSLC links currently work in the
> > > defining of a relationship is accurate. There has been some
discussion
> > > about the merit of such a design, since it is exposed to a
fragility,
> > > namely, that for each link, there should be a corresponding link in
the
> > > other direction. The need for the "backlink" as it has been called,
> aids
> > > navigability (we typically want the relationship to be navigable in
> both
> > > directions). It is also reasonably easy to implement.
> > >
> > > The fragility is maintaining this invariant: for example, when a
> > > resource is deleted, any "backlinks" to that resource should be
> removed.
> > > There are other "relationship management" designs which don't have
this
> > > weakness.
> > >
> > > My reading of Simon's document is that it is talking about these
> > > relationships, rather than the lower-level "nuts and bolts" of how
one
> > > resource links to some other resource. We need to think about how we
> can
> > > uniformly manage these relationships across all the domains.
> > >
> > > best wishes,
> > > -ian
> > >
> > > ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> > > Chief Software Architect, Requirements Definition and Management
> > > IBM Rational
> > >
> > > From: James Conallen <jconallen at us.ibm.com>
> > > To: Benjamin Williams/UK/IBM at IBMGB
> > > Cc: Ian Green1/UK/IBM at IBMGB, oslc-rm at open-services.net
> > > Date: 06/10/2009 16:44
> > > Subject: Re: [OSLC-RM] Link types
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > I have one concern about the link types document's attempt to define
> > > *both* the forward and reverse links. I believe that the general
OSLC
> > > mechanism for creating bi-directional links is to create two
> > > unidirectional links managed by each server, and hope that it is
> > > possible with a query on the other server to find the right back
link
> > > when deleting.
> > >
> > > If this is the case, then we should probably restrict the definition
of
> > > the link types to those that are managed by the OSLC RM implementing
> > > service, and not make assumptions that all the other services (i.e.
> OSLC
> > > CM, OSLC AM, OSLC QM, ...) will support these OSLC RM defined link
> types.
> > >
> > > In the OSLC AM space our scenarios have all sorts of link types that
> are
> > > referenced. For example a model element can implement a requirement,
or
> > > specify a requirement, or a requirement resource can be
documentation
> > > (i.e. how to guide) for a model element. Given that both models and
> > > requirements can be used in many different ways, it is hard to pin
> down,
> > > generically, just a few relationship types between AM resources and
> > > requirements. With this said, if we just say that links from
> > > Requirements to Architecture Management Resources will be one of
> > > (modeledBy, realisedBy or incorporatedBy) that will be fine from an
> OSLC
> > > AM client point of view.
> > >
> > > <jim/>
> > >
> > > jim conallen
> > > jconallen at us.ibm.com
> > > Rational Software, IBM Software Group
> > >
> > >
> > >
> > > Inactive hide details for Benjamin Williams ---10/06/2009 10:22:09
> > > AM---Ian As per my other email on reporting, I feel that sucBenjamin
> > > Williams ---10/06/2009 10:22:09 AM---Ian As per my other email on
> > > reporting, I feel that such such collaboration
> > >
> > >
> > > From:
> > > Benjamin Williams <bwilliams at uk.ibm.com>
> > >
> > > To:
> > > Ian Green1 <ian.green at uk.ibm.com>
> > >
> > > Cc:
> > > oslc-rm at open-services.net, oslc-rm-bounces at open-services.net
> > >
> > > Date:
> > > 10/06/2009 10:22 AM
> > >
> > > Subject:
> > > Re: [OSLC-RM] Link types
> > >
> > > Sent by:
> > > oslc-rm-bounces at open-services.net
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Ian
> > >
> > > As per my other email on reporting, I feel that such such
collaboration
> > > and consistency across domains will be extremely important, if not
> > > absolutely necessary.
> > > Specifically in the context of reporting, the features exposed by
> > > service providers across each domain will need to (consistently)
> support
> > > the requirements and use-cases defined in the Reporting domain such
> that
> > > reporting consumers can leverage lifecycle data without needing any
> > > knowledge of the source domains and any differences in the way they
> > > expose data.
> > >
> > > The scenarios and use-cases that we are defining in the reporting
> domain
> > > should be entirely domain agnostic, as far as I am concerned. We can
> use
> > > specific examples for both single domain reporting as well as cross
> > > domain reporting, but the domains used in the examples should be
freely
> > > interchangeable without any impact on the reporting consumer.
> > >
> > > The reporting domain is still in its infancy, and my involvement in
> OSLC
> > > is only just beginning, but from what I understand, the reporting
> domain
> > > might be one of the first things to force us to think about some of
the
> > > cross domain issues that you and Simon have discussed.
> > >
> > > /Ben
> > >
> > >
> >
>
-----------------------------------------------------------------------------
>
> > > Benjamin Williams
> > > Senior Product Manager - Rational Publishing Engine
> > >
> > > Email: bwilliams at uk.ibm.com
> > > Tel: +44 20 8818 4360
> > > Cell: +44 7710 637 067
> > > IBM Extension: 364360
> > > IBM ITN: 37364360
> > >
> >
>
-----------------------------------------------------------------------------
>
> >
> > >
> > >
> > > From: Ian Green1/UK/IBM at IBMGB
> > > To: "Simon Wills" <simon.wills at integrate.biz>
> > > Cc: oslc-rm at open-services.net
> > > Date: 06/10/2009 14:16
> > > Subject: Re: [OSLC-RM] Link types
> > > Sent by: oslc-rm-bounces at open-services.net
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > > Hello Simon,
> > >
> > > this is good progress both on explaining our current position w.r.t.
> > > link types, and also taking a longer term view of the role we see
link
> > > types playing the future. Thanks very much for putting this
together.
> > >
> > > Steve/Scott: whilst there is no pressure as yet to drive this
forward,
> > > Simon makes a good case for any such effort to be cross-OSLC
domains.
> > > How do you see this shaping up over time? Is there some tension
between
> > > designing an OSLC-wide vocabulary and being entirely
scenario-driven?
> > >
> > > best wishes,
> > > -ian
> > >
> > > ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> > > Chief Software Architect, Requirements Definition and Management
> > > IBM Rational
> > >
> > > From: "Simon Wills" <simon.wills at integrate.biz>
> > > To: Ian Green1/UK/IBM at IBMGB
> > > Date: 05/10/2009 15:42
> > > Subject: Link types
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > > Hi Ian
> > >
> > > Just to let you know ... I've put a new section titled 'Discussion
> > > Topics' in the right hand sidebar of the main RM page, and put a
link
> to
> > > a discussion document on link types (at
> > > _http://open-services.net/bin/view/Main/RmDiscussionLinkTypes_).
> Haven't
> > > quite sussed out how to format tables properly in the Wiki editor,
but
> > > the content is all there.
> > >
> > > Would you like me to put out an announcement on the mailing list?
> > >
> > > Cheers
> > >
> > > Simon
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > Simon Wills
> > > Managing Director *
> > > integrate systems engineering ltd*
> > > m: +44 (0)7967 091824
> > > t: +44 (0)1225 859991
> > > f: +44 (0)1225 859993
> > > e: simon.wills at integrate.biz
> > > w: _www.integrate.biz_ <http://www.integrate.biz/>
> > >
> ------------------------------------------------------------------------
> > >
> > >
> > >
> > >
> > >
> ------------------------------------------------------------------------
> > >
> > > /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-RM mailing list
> > > OSLC-RM at open-services.net_
> > >
__http://open-services.net/mailman/listinfo/oslc-rm_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-RM mailing list
> > > OSLC-RM at open-services.net_
> > >
__http://open-services.net/mailman/listinfo/oslc-rm_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-RM mailing list
> > > OSLC-RM at open-services.net
> > > http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
> >
> > _______________________________________________
> > OSLC-RM mailing list
> > OSLC-RM at open-services.net
> > http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
> >
> >
>
> _______________________________________________
> OSLC-RM mailing list
> OSLC-RM at open-services.net
> http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
> _______________________________________________
> OSLC-RM mailing list
> OSLC-RM at open-services.net
> http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
>
> _______________________________________________
> OSLC-RM mailing list
> OSLC-RM at open-services.net
> http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
>
> [attachment "pic27215.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic20377.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic05643.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic22755.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic07856.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic15922.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic19437.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic26054.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic18683.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic01032.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic26797.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic13483.gif" deleted by James Conallen/Philadelphia/IBM]
> [attachment "pic24770.gif" deleted by James Conallen/Philadelphia/IBM]
> _______________________________________________
> OSLC-RM mailing list
> OSLC-RM at open-services.net
> http://open-services.net/mailman/listinfo/oslc-rm_open-services.net
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20091007/5e0f939d/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-rm_open-services.net/attachments/20091007/5e0f939d/attachment.gif>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-rm_open-services.net/attachments/20091007/5e0f939d/attachment-0001.gif>
More information about the Oslc-Rm
mailing list