- 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
