Why are RDF root elements being used? I thought the recommendation was going to be not to do this.. and that CM doesn't do it. So this is neither following the future recommendation or adhering to the 1.0 convention established in CM. I would have expected (eg) the root element of the requirement to be oslc_rm:Requirement.

Scott: Steve feels this is a serious issue that needs to be resolved. Need to take a short-term decision to align with CM specification. Actoin on img to pursue this with SteveA? . Dominic: could we make it optional?

(2) In a requirement: If dc:creator is read only, how is it initially established? Ditto for dc:creator -- do we say something about how the identity of the creator is known to the service for these? Or is the point that they are optional because the service may not have a means for determining the creator, and read-only because we're not allowing the client to specify? (I realize this problem exists in other specs but it struck me while reading RM).

Chris: big ask that service provider knows the identity of the user? Dominic: auditing etc. Chris: document that system requires this behaviour. Rainer - is the creator the one who types it in, or the user of the system. Need to align with all the other domains. CM spec does it this way as well - read-only and optional. Rainer - "proxy" or "impersonation" should be separate and addressed in separate scenarios.

Requirements Collection Resource -- seems not to be a resource at all, but rather the assertion that OSLC RM service providers mus represent Requirements Collections as RDF list items. Unless I'm mistaken, this resource has no elements from the oslc_rm namespace. Right?

It is also strange to me that we have a collection resource that doesn't tell me how to change the state of the collection. This is a 'read only' collection?

All: discussion around rdf:Bag. Add - rdf:type oslc_rm:RequirementCollection.

In http://open-services.net/bin/view/Main/RmDelegatedResourceSelectionV1 -- it says that "The substantive difference is the ommission of resource creation" but there is a section on Resource Creation. In that section, there is still CM-specific language under "prefilling creation dialogs." RM is or isn't supporting creation? I assume it is a Yes. I'm not 100% comfortable with the language that we used in CM for defining the behavior of the creator -- it is confusing. I'd rather describe the the services as a "form factory" which responds to POST by creating a single-use form. This is the rationale for the 201 Created -- we created a form. This does not come out in the spec.

Action on img: talk to SteveA? about oslc_sd:Dialog etc. and whether to rename to oslc_rm.

Why wouldn't we name creation and selection dialogs using names that are analogs of the CM ones -- . creator / factory / selector is less descriptive (to me) than creationDialog, selectionDialog, and factory. http://open-services.net/bin/view/Main/RmRestApiV1 seems to use the CM terminology, but http://open-services.net/bin/view/Main/RmServiceDescriptionV1 uses creator/factory/selector.
The oslc_sd namespace is new to me -- I don't think I understand the role that this is playing. I have a feeling this is related to the inconsistency between (eg) a requirementSelector and a selectionDialog... is this simply an RDF-ifying of the discovery resources by introducing an oslc_sd:Dialog RDF type?