I missed the last call due to a conflict. Is this an issue of being able to categorize Automation providers so it is possible to return Automation Plans for a given category (e.g., Test vs Build). If so did you discuss the ability to have hierarchical categorization? The thought is that I may want to search for all "test" providers and be able to select "performance test" plans vs "functional test" plans.
Regards, Daniel Berg STSM, Master Inventor IBM Rational, DevOps Lead 1-919-486-0047 | Cell: 1-919-637-8570 From: [email protected] To: [email protected], Date: 07/19/2012 12:04 PM Subject: Oslc-Automation Digest, Vol 17, Issue 17 Sent by: [email protected] Send Oslc-Automation mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit http://open-services.net/mailman/listinfo/oslc-automation_open-services.net or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Oslc-Automation digest..." Today's Topics: 1. type issue (John Arwe) ---------------------------------------------------------------------- Message: 1 Date: Thu, 19 Jul 2012 11:34:19 -0400 From: John Arwe <[email protected]> To: [email protected] Subject: [Oslc-Automation] type issue Message-ID: <ofca7ed958.650a1372-on85257a40.0050dd5a-85257a40.00558...@us.ibm.com> Content-Type: text/plain; charset="us-ascii" - I added the dcterms:subject proposal discussed during the call, and verified (to my satisfaction at least) that it fits with Dublin Core's intent and specification. - I think using either dcterms:subject or oslc:usage is fundamentally equivalent in terms of their existing capabilities. Neither requires new invention beyond defining URIs for "common" categories of automation (indeed, all proposals share this feature). With just a bit of awkward-seeming repetition in the SP document, oslc:domain offers capability equivalent to the other two. - Using oslc:domain has the drawback that existing cardinalities are restricted in certain cases. oslc:domain is 1:1 on Service, 0:* on Service Catalog. - Using oslc:domain has the drawback that its definition says that its URI identifies a namespace specification. I don't view #Test, #Build, etc as separate specifications or namespaces, either real or conceptually as things currently stand. If someone asked me to distinguish them based on spec content, I'd be dancing mightily. - Using oslc:usage has the drawback that it is only spec'd on lower level resources (Creation Factory, Query Capability, Dialog - it is 0:* on all of those). It is still usable in other contexts like Service Provider, as is any vocabulary term with relevant semantics. Aside from providing a URI to communicate "default", which is not a conflict with dcterms:subject, and its explicit guidance that usage values are domain-specified, which is also not a conflict with dcterms:subject, I'm not seeing anything aside from existing client base/history that really leads one to prefer either over the other. - Using oslc:usage has the drawback that it is more work for clients to use than oslc:domain; there are more places to look, Service Provider is not one specifically called on in existing specs, and it is optional everywhere while domain is required on Service. - Using dcterms:subject has the drawback that it is not called out in the existing Core specs, so there is no OSLC client base/history already existing that we'd re-use if we chose it. Looking at the discussion generically as a categorization problem, I believe we want tools (and users) to have essentially arbitrary flexibility in terms of defining categories that make sense for their scenarios, with any single resource potentially fitting into 0:* categories. This means the 1:1 limit on oslc:domain for a Service "feels" over-constraining to me. The natural counter being that nothing prevents a SP from duplicating the Service with a distinct value for each category (awkward perhaps, but certainly within spec bounds). This leads me to dislike oslc:domain, and very weakly prefer oslc:usage over dcterms:subject (based on original intent of usage, and existing client base). Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario -------------- next part -------------- An HTML attachment was scrubbed... URL: < http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120719/8a5edb06/attachment-0001.html > ------------------------------ _______________________________________________ Oslc-Automation mailing list [email protected] http://open-services.net/mailman/listinfo/oslc-automation_open-services.net End of Oslc-Automation Digest, Vol 17, Issue 17 ***********************************************
