Feedback on DPV Primer's draft

Dear Harsh,

thank you - and everyone who contributed - for the great job in drafting 
the primer.  I find it well structured, well written and crystal clear, 
even if it explains nontrivial concepts.  Well done!

If I may, I would like to suggest a minor refinement.

Consider Example 2 (Extending Market concept to represent granular and 
accurate Purposes).  This example could still be debatable, since the 
term "MarketingSeasonalOffer" itself could be made even more specific - 
say - by restricting it to a specific marketing campaign by a single 
company (eg Gucci) and for a specific season (eg Christmas 2021).  In 
other words, MarketingSeasonalOffer still looks like a class.

Now suppose DPV is used for expressing consent in this context.  If 
MarketingSeasonalOffer is an instance, then it can't be refined to refer 
*only* to Gucci's 2021 Christmas campaign. Therefore, a data subject 
cannot opt in *only* for this particular marketing campaign: the options 
are either all MarketingSeasonalOffers hereafter (by all companies), or 
nothing.

If the above example of an instance (Gucci's campaign, autumn 2021) 
looks too complicated, then this example may be replaced with one about 
the class Recipient, of which Google (or any other company) can be an 
instance.  In my opinion, recipients and controllers cover most of the 
very few cases in which you may really happen to want an instance 
instead of a class.

There are other examples in the primer where instances are probably 
better modelled as classes:  for example TVServiceOptimisation (could be 
restricted to specific services); CombinedNewPurpose in Example 5 (could 
be restricted to specific kinds of good delivery or specific companies), 
LimitAccess in Ex. 6 (different policies determine different 
limitations, eg. only working hours, no weekends, no access at all), and 
so on....

By the way: In the primer, it could be useful to remind somewhere that 
if a term is an instance, then it can't be further 
refined/subclassed/restricted by another term.  Thus, it is a sort of 
point-of-no-return.  Use instances with care!  Instances jeopardize 
extensibility and interoperability as illustrated in sections 4.2 and 4.3.

Best regards, and many thanks again to all authors for an excellent job.

Piero

On 01/01/22 13:34, Harshvardhan J. Pandit wrote:
> Hello, and welcome to a new year. Hope it is happy, safe, and productive.
> 
> We now have a draft for a Primer to the DPV. I'm hoping to finalise this 
> by month-end, JAN-31. Please submit your comments/suggestions/feedback 
> before then. You can email to the mailing list, me directly, fork the 
> repo, send an annotated document, etc.
> 
> Primer: https://harshp.com/dpv-x/primer/
> GitHub (HTML and DOCX): 
> https://github.com/coolharsh55/dpv-x/tree/master/primer
> 
> There is a list of issues at the bottom for diagrams and examples to be 
> added: https://harshp.com/dpv-x/primer/#issue-summary
> 
> Other than these, please let us know if there is any additional 
> information to be added, something isn't clear, needs more/better 
> examples, etc.
> 
> The Primer is intended to be the starting document for people new to the 
> DPV. The specification is intended to act as a 'technical reference' of 
> its concepts. These are part of planned documentation, which also includes:
> 
> 1. Specification (exists at: https://www.w3.org/ns/dpv)
> 2. Primer (this email)
> 3. Examples library (e.g. in RDFS, OWL, JSON-LD) - todo
> 4. Use-cases (collecting requirements for concepts and examples) - todo
> 5. Tutorials (opinionated guides to building things with DPV) - todo
> 6. Explanations (for design choices and issues in DPV) - todo
> 
> Regards,

Received on Thursday, 27 January 2022 15:53:07 UTC