>From a security/auditing/traceability standpoint, I'd one the (at least one) value to be the human corresponding to the principal in the credentials used to authorize the request when it was created. That is "on whose behalf" the work the result was created; that is important for some applications. Even timer-based processes have some security context, and hence an associated principal whose privileges they use to run. >From a different kind of traceability standpoint, e.g. for debugging, which actor - possibly externalized as a foaf:Agent - actually "physically" created the resource is the more interesting question. There might be varying levels of encapsulation involved as well (your "is the agent/worker thread part of the SP" question pokes at this), and how many get exposed may be configurable; a private cloud might allow more transparency than a public cloud. A fair amount of similarity to HTTP Server header's behavior actually, and for similar reasons. I would lean toward allowing all of those to be expressible. I would not object to mentioning foaf:Agent as well as Person, but I would not demand that either since it is not limiting. If you're looking for more in-line guidance, I might volunteer: One likely object is the Person on whose behalf the automation result was created; other potential objects are Agent(s) who acted on the Person's behalf.
Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario From: Michael F Fiedler/Durham/IBM@IBMUS To: [email protected] Date: 09/04/2012 08:05 PM Subject: [Oslc-Automation] dcterms:creator for Automation Result Sent by: [email protected] The current definition of Automation Result has a zero-or-many dcterms:creator predicate which is described as likely to be a FOAF Person. Does it make sense to have a creator for Automation Results which is described as likely to be a Person? Since the Result is most likely to be created by the service provider (or perhaps an agent/worker), should we keep it at all? or state it is likely to be the URI of the service provider itself? Any implementation feedback here? Regards, Mike Michael Fiedler IBM Rational Software [email protected] 919-254-4170_______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net
