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. Ian: Ruling out root element now is reasonable, but indications are that this will not be acceptable in the future (OSLC Linking spec.). Dominic: could we make <RDF/> element optional - as the W3C? does in the RDF/XML spec.? Action on img to pursue this with SteveA? .

img: After discussion with Steve, have removed all the RDF root elements from the resource definitions. Consistency with the existing specifications and OSLC resource design guidelines motivated this change.

(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. seems to require this, however. Chris: document that system requires this behaviour. Rainer - is the creator the one who types it in, or the user of the system. Rainer's main concern was consistency across OSLC - we need a consistent notion of, for example, dc:creator. Need to align with all the other domains. Rainer: CM spec does it this way as well - read-only and optional - so it is good that CM and RM are consistent. 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: yes, the scenarios don't require update to these collections.

All: discussion around rdf:Bag. Add - rdf:type oslc_rm:RequirementCollection. Action on ian: add rdf:type assertion to the specification.

img: done 2009-12-17.

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.

Agreed: i've updated this, removed CM-specific material and hopefully improved the presentation.

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

img: I struggled to get time to discuss this with Steve so have assumed the worst and renamed away from OSLC Commons to oslc_rm namespace. Discussed this with Reporting workgroup and agreed we will try to align during 2010.

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?

Img: I've done this renaming, to both RmDelegatedUIV1, RmRestApiV1, and /RmServiceDescriptionV1 and I encourage others to review and feedback.