[Oslc-Automation] Oslc-Automation Digest, Vol 17, Issue 17

[Daniel Berg]

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:	oslc-automation-request at open-services.net
To:	oslc-automation at open-services.net,
Date:	07/19/2012 12:04 PM
Subject:	Oslc-Automation Digest, Vol 17, Issue 17
Sent by:	oslc-automation-bounces at open-services.net



Send Oslc-Automation mailing list submissions to
		 oslc-automation at open-services.net

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
		 oslc-automation-request at open-services.net

You can reach the person managing the list at
		 oslc-automation-owner at open-services.net

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 <johnarwe at us.ibm.com>
To: oslc-automation at open-services.net
Subject: [Oslc-Automation] type issue
Message-ID:

<OFCA7ED958.650A1372-ON85257A40.0050DD5A-85257A40.00558982 at 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
Oslc-Automation at open-services.net
http://open-services.net/mailman/listinfo/oslc-automation_open-services.net


End of Oslc-Automation Digest, Vol 17, Issue 17
***********************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120719/ae2ff2d2/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-automation_open-services.net/attachments/20120719/ae2ff2d2/attachment.gif>