[Oslc-Automation] type issue

[John Arwe]

- 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-0003.html>