Simple answer, my reading is that either representation is allowed; I think that is in line with the authors' intent (speaking as one of them, and as the motivator/advocate for this style in 2.0). The implementation I am familiar with using this style uses the second form (multityping).
"always 404" allowed? yes. 2.0 does not specifically encourage this behavior, but again it is allowed by what is said. Indeed it must be by some reckonings, otherwise server implementations would be constrained from ever garbage-collecting old resources even if failing to do so crashed said servers. > If that is true, then is the URI still needed in the RDF in order to have a value to set for the oslc_auto:producedByAutomationRequest property, That property is 0:1 in the spec, so (definitionally) I think the answer is no URI is required; could be a blank node. If both are present and have different values (that is: the "create AutoRequest response is or contains both an AutoRequest and an AutoResult, all components of the response have URIs, *and* this predicate has a different URI than any of the preceding"), then I think the server is providing an inconsistent response and I (as a client) would treat that as an error if I detected it. A simple client would probably assume that any AutoResult contained in the response message was "the AutoResult", and would expect to dereference its URI (if any) in cases where the AutoResult's state/verdict are still changing (exact conditions noted in 2.0 spec). > or if an automation request also has an rdf:type property set to oslc_auto:AutomationResult, is it valid to assume that that is the result for that request? I don't recall the 2.0 spec explicitly saying if such an assumption MUST be made, SHOULD be made, or MAY be made. Many specs (including OSLC) are silent on some cases, sometimes intentfully and sometimes via simple omission. Writing single specs usable by providers (who often want to know Only What I Must Do) and consumers (What Can I Rely On) is a balancing act, and one form of response is the existence of companion documents like the Primer. In those cases, the common strategy is to mostly limit the normative spec to what providers need to know, and expand upon that (and its implications) in the informative companion documents. I think this is what Automation attempts, although I freely admit energy to flesh out the informative material wanes ... as you will no doubt find when following the link below. > useful to explicitly mention the situation where the request and response are the same resource, and probably include an example too. Fine candidate for http://open-services.net/wiki/automation/OSLC-Automation-Primer-2.0/#Synchronous-scenarios . Should be able to point to the ibm.com manuals on the Jazz for Service Management Resource Registry (part of Registry Services) for the multityped case, too. The Primer should not be access-controlled, so you can just edit and point the list at it for reviews. Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
