RE: [oslc-promcode] provider/client design problem about collects from Plan or Report

[Kazuhiro Funakoshi <k-f@bk.jp.nec.com>]

Arthur,

Thank you for TRS pointer. I didn't know this. I will take a look.

Sorry for my bad explanation. I did not intend to say about query mechanism but PROMCODE service provider behavior:

Precondition:
For a plan <p> collects WorkItem <w>,
<p> a promcode:Plan;
  promcode:collects <w>.

<w> a promcode:WorkItem.

Situations:
(1) create sub-WorkItem <w'>, (<w'> promcode:isPartOf <w>);
(2) create super-WorkItem <w'> (update <w>, <w> promcode:isPartOf <w'>);
When we have an isolated WorkItem <w'>,
(3) create sub-WorkItem of <w> and super-WorkItem of <w'> as <w''> (→:isPartOf, <w'> → <w''> → <w>);

Question:
Q1: Should <p> collects <w'> automatically at least when respond to a GET request on <p>?
Q2: What about other resources ScopeItem, WorkItem and Artifact which are associated with <w> ?
Q3: If yes, when should it be done: In POST time or GET time (lazy way) ?
Q4: If yes, should it be done at service provider side or client side?

Yesterday I had a chance to talk this with Mr. Wakao and Mr. Matsumoto. The conclusion there was, we should keep query capability as MAY and no complicated logic with ManagedItemCollection. It means that promcode:collects is always complete and maintained by stakeholders as their intention. Thus, the answers to Q1, Q2 above are "No".  I agree with this, because it keeps implementation simple.

In our scenario Example 15, the plan <200> collects scope item <1010>, it means supplier needs neither work item <3010>(Example 11) nor artifact <2010>(Example 10).
If supplier needs them, then acquire has to make a plan collects them.
Note that Fig. 9 says excel adaptor issues GET at WorkItem, so Example 15 is going to be updated to collect <3010> at least.

-----Original Message-----
From: Arthur Ryman [mailto:arthur.ryman@gmail.com] 
Sent: Friday, July 10, 2015 12:19 PM
To: Funakoshi Kazuhiro(船越 和大)
Cc: oslc-promcode@lists.oasis-open.org
Subject: Re: [oslc-promcode] provider/client design problem about collects from Plan or Report

Kaz,

We have a classic tradeoff here. On the one hand, people want complex queries. On the other hand, people want to simplify implementation. So if the PROMCODE server does not provide a SPARQL endpoint, then it could provide a Tracked Resource Set interface so that an external indexer, such as the Jazz Lifecycle Query Engine (available in the Jazz Reporting Services) can pull the data out of the PROMCODE server into an external SPARQL endpoint.

My recommendation is that we don't invent another query mechanism.
Either the PROMCODE server has a built-in SPARQL endpoint or it provides a Tracked Resource Set interface.

-- Arthur

On Mon, Jun 29, 2015 at 1:39 AM, Kazuhiro Funakoshi <k-f@bk.jp.nec.com> wrote:
> Dear TC members,
>
> As subclasses of ManagedItemCollection, we have four: Plan, Report, 
> IssueCollection and RiskCollection. To traverse in these collections, we have a design problem: what they should collect.
> Especially in Plan and Report, they can collect any ManagedItems. 
> However, imagine when we want to obtain series of Artifacts from a plan, what we can do is:
>
> 1. Directly find from Plan collects property.
>   To do this, we have guarantee that the Plan collects all of Artifacts which relates to the Plan.
>
> 2. Filter from ManagedItemContainer.
>   2.1 By SPARQL
>     We didn't make Query Capability as MUST, so we cannot expect this always work.
>   2.2 Client side filter operation
>     First we have to get all items, then filter with:
>     (1)*{ (2) + (3) + (4) + (5) + ...}
>     (1) is an Artifact
>     (2) the Plan collects
>     (3) a ScopeItem which has producedFor range of the Artifact and collects range of the Plan
>     (4) a WorkItem which has producedFor range of the Artifact and collects range of the Plan
>     (5) a WorkItem which has producedFor range of the Artifact and has requiredBy to a ScopeItem which the plan collects
>     (...) we also have to consider isPartOf relation, it may have a deep hierarchy.
>
> Query in 2.1 and 2.2 should have same logic, they don’t seem smart.
>
> 1. helps but does not simplify the problem drastically. We still have 
> to think POST/PUT/PATCH operations for ManagedItems which can make disconnected items connected.
>
> Remind we had inverse properties long time ago. During that time we 
> had a discussion that SPARQL query will solve problem so we deleted them. Actually, that design also have a problem shares the root: how to keep consistency (property・inverse ≡ id).
>
> Before next meeting, I think we should at least make pros/cons clear.
> If you find something wrong/oversight, feel free to reply to this mail as well as idea/comments.
>
> Regards,
> Kaz

Attachment: smime.p7s
Description: S/MIME cryptographic signature