• Continuation of discussion from 5th September around extending the set of known link types in the RM v2.0 specification.

Attendees: DominicTulley (Chair), SimonWills , VishyRamaswamy, JimConallen, MichaelFiedler , Clyde Icuspit

Apologies: Ian Green

Minutes:

Two issues were discussed. The initial issue was to identify how we can easily add new link types to the RM specification without going through a full release cycle for it.

The AM specification currently supports a dynamic link type mechanism rather than having built in link types. This mechanism means a client would request a service provider to tell it about all the types of links it will allow the client to make.

This was discussed at some length and was thought worthy of pursuing for RM. As such it was observed that it should probably be an OSLC_Core mechanism rather than RM developing a clone of what AM has today. It was also suggested that one way to move from what we have today to a dynamic mechanism would be to move our existing built in types to be a non-normative set of "recommended" types that a system might support. This was not heavily discussed.

Jim suggested a smaller group get together to hammer out some of the details (the AM mechanism could do with a little refining) and then, if agreeable, it could be taken to the Core team.

Jim, Vishy and Dominic volunteered to be on this groups. Ian was volunteered by Dominic and Simon asked to be included as an optional participant. It was agreed that the email discussion would be sent to the OSLC_RM and OSLC_AM mailing lists so all members would be aware of the discussion even if they did not choose to participate directly.

During this discussion a second issue was identifed, which was that we are looking for a quicker way to introduce certain link types which are noteably absent from the existing 2.0 specification (these being oslc_rm:elaborates and oslc_rm:specifies). It was initially thought that these could simply be treated as errata given that the "other end" of the links was included in the speci (ElaboratedBy? and SpecifiedBy? ) but a conclusion was not reached on quite how obvious this was. Jim observed that the specification should not imply that if an ElaboratedBy? relationship exists then an Elaborates one will exist "in the other direction". It would probably be acceptable to define Elaborates and ElaborateBy? as two distinct link types/link roles without declaring any special relationship between the two, but this begs the question- should we do it for all the link types we support?