OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-promcode message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: provider/client design problem about collects from Plan or Report


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]