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

[Arthur Ryman <arthur.ryman@gmail.com>]

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