[Oslc-Automation] type issue

[Paul McMahan]

John,

Great writeup.   I agree with your assessment and that olsc:usage seems to
be the best of the three options.

Unfortunately I won't be able to attend the automation workgroup meeting
today due to a conflict.   So I'll keep an eye out for the meeting notes
and any further discussion on the mailing list.


Best wishes,
Paul McMahan
IBM Rational



From:	John Arwe/Poughkeepsie/IBM at IBMUS
To:	oslc-automation at open-services.net
Date:	07/19/2012 11:39 AM
Subject:	[Oslc-Automation] type issue
Sent by:	oslc-automation-bounces at open-services.net



- 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
_______________________________________________
Oslc-Automation mailing list
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net