Template for requirements

From Data Privacy Vocabularies and Controls Community Group

Overview

Creating Requirements

  • Each use case will be analysed and a final set of requirements developed (per UC) and then normalised
  • Each requirement will then be categorised into:
    • Requirements related to xxx
    • Requirements related to yyy
    • Requirements related to zzz
  • Within each of these categories, each requirement will be noted as:
    • An extension or addition
    • A change to the existing
    • A removal/deprecation
  • Criteria will then be applied to ranked/order each requirement, including:
    • Business support for this change
    • Commonality of the change (ie not specific to a domain/sector)

Discussing and approving requirements

All members of DPVCG are invited to comment on requirements. Any comment should include the name of the author of the comment and optionally a timestamp. (Please take care that 2 empty lines are between the last comment of a requirement and the heading of the next one.)

Each requirement has a status which indicated by one of the following:

  • Status: Proposed
  • Status: Under consideration
  • Status: Approved or Partially Approved (optional: <link to relevant resolution>)
  • Status: Rejected or Migrated (to another Requirement)

All members of DPVCG are invited to vote on requirements to get them to the approved or rejected status.
For a vote please add your name or initials to the Vote item by using

  • +1 for approving it
  • -1 for rejecting it
  • 0 to indicate this requirements needs further clarification (you should add a comment too)

Below each requirement this list of items should be shown:

  • ReqType: ...
  • Source: ... (cross-reference to each use case supporting this requirement, along with an optional one sentence justification)
  • See also requirement: ... (optional)
  • Status: ...
  • Vote:
  • Discussion (below):


Example Requirements

POE Requirements Wiki

https://www.w3.org/2016/poe/wiki/Requirements

Example: POE.R.DM.02 Define target of a constraint

By the current specification - http://w3c.github.io/poe/model/#constraint - a constraint applies to a Permission, Prohibition or Duty as a whole.
Uses cases show that it should be possible to define the target of a constraint inside a Permission, Prohibition or Duty: e.g. a constraint of human age applies to the Assignee, a constraint of play time applies to Assets (of type audio or video), etc.

Example: POE.R.DM.07 Define a category property for class Party

A property of the class Party should define the category of the Party.

Renato Iannella What is the Use Case? We deliberately left out defining any characteristics of Parties (except for UID, role) and suggested using external Vocabs (eg vCard)

If the current text of UC.01 R17 is not sufficient to show the need for this requirement then the contributor should refine it, please Michael Steidl 2016-06-09T06:45:00Z

Víctor Rodríguez-Doncel 08:31, 9 June 2016 (UTC): While having a minimal vocabulary is a good design choice, some kinds of parties are mentioned very recurrently in actual licenses/policies. For example, "academic users" (users belonging to an entity of academic nature), "non-academic users" or having membership in a particular institution.

Renato Iannella is an example use case the ability to state that the Assignee of a policy is any party of category "academic user" ? Or is it that the use of the content is only allowed by parties of category "academic user"?

Víctor Rodríguez-Doncel (talk) 11:42, 25 August 2016 (UTC): Within the CLARIN licenses for language resources Clarin conditions, one of the requirements is AFFIL "The user needs to be affiliated with some community, e.g. a community of researchers through a university or research institution (x=EDU) or a community of language research and technology researchers more generally (x=META)". It should be expressable that the assignee of the policy is any party of category EDU.

Michael Steidl 2016-09-06 17:38: Victor, I think this need can be covered by a constraint which targets the Assignee party. See the Requirement above.

SHACL Requirements Wiki

https://www.w3.org/2014/data-shapes/wiki/Requirements

Example: Property Labels at Shape

It should be possible to provide human-readable labels of a property in the context of a shape, intended for human consumption such as documentation or UI, not just globally for the rdf:Property. Multiple languages should be supported.

  • Status: Approved Teleconf 19 March 2015
  • Derived from: S11, S19
  • Votes: HK, ericP:0, pfps:-0.5, SSt:0, KC+1, AR: +1
  • Comment (pfps): This does not seem to be helpful. What good would such labels be?
  • Comment (HK): One advantage is useability: the same constraint can be used to fully describe a property, without having to fall back to a global property triple in some other part of the document. This is important, e.g. when such shape/class declarations are serialized in Turtle and JSON. Another advantage is that sometimes the label of a property at a shape/class is different from any potentially global label. We have examples for this in the EPIM project (npd:id sometimes should be displayed as "well bore id" and "facility id").

DPVCG Requirements

Retrieved from "https://www.w3.org/community/dpvcg/wiki/index.php?title=Template_for_requirements&oldid=131"