# Re: some more comments on the paper drtaft and spec

From: Javier D. Fernández <jfergar83@gmail.com>
Date: Sun, 28 Jul 2019 20:51:07 +0200
Message-ID: <CACQD0wV2ryPx1H-0gTqM68oQwPkYENQpYtKwFDHG-=d18_OBuQ@mail.gmail.com>

Cc: Axel Polleres <axel.polleres@wu.ac.at>, "simon.steyskal" <simon.steyskal@wu.ac.at>, apollere <apollere@wu.ac.at>, public-dpvcg <public-dpvcg@w3.org>
I agree with Axel and Piero,

Of course instancing could be another way to do it, but I think we early
decided to follow the SPECIAL approach and use subclassing. This allows for
flexibility and reasoning strategies as mentioned by Piero. At the end of
the day, I can imagine that it would be relatively infrequent to have a
named instance of a purpose per se (e.g. it would be the concrete "item",
text. etc., reflecting the purpose class), and more common to have a full
policy using those classes to compose its components.

Best,
Javier

On Sun, Jul 28, 2019 at 12:13 PM Piero Bonatti <pieroandrea.bonatti@unina.it>
wrote:

> Subclassing IMHO is preferrable because it is more general.
>
> It encompasses instances throug singleton classes, when needed (for
> example in SPECIAL we are using this approach for dynamic consent).
>
> Subclassing gives full flexibility and an amazing range of granularity
> choices, including co-existence of orthogonal formalizations.
>
> Best,
> Piero
>
> On 25/07/19 17:27, Axel Polleres wrote:
> > FWIW, I think subclassing was so far the mechanism we areed upon (and
> which is compatible with SPECIAL's compliance checking algorithm as
> well),so I'd prefer to keep that...
> > Would appreciate Piero's and/or Javier's comments here!
> >
> > Axel
> >
> > Prof. Dr. Axel Polleres
> > Institute for Information Business, WU Vienna
> > url: http://www.polleres.net/  twitter: @AxelPolleres
> >
> >> On 25.07.2019, at 17:24, simon.steyskal <simon.steyskal@wu.ac.at>
> wrote:
> >>
> >> isn't it just personal preference though?
> >>
> >> while it certainly makes sense to use sub classes for more generic
> purposes, I wouldn't create a sub class for each and every purpose..
> >>
> >> just my 2 cents,
> >> simon
> >>
> >> -------- Original message --------
> >> From: apollere <apollere@wu.ac.at>
> >> Date: 25/07/2019 07:00 (GMT+01:00)
> >> To: public-dpvcg@w3.org
> >> Subject: some more comments on the paper drtaft and spec
> >>
> >> While Harsh and myself are working on the paper draft for ODBASE (again,
> >> feel free to also comment/help),
> >> I was reading over the spec text for personal data categories again,
> >> where it says:
> >>
> >> "We therefore suggest to declare the specific context as an instance of
> >> one or several dpv:Purpose categories and to always declare the specific
> >> purpose with a human readable description (e.g., by using rdfs:label and
> >> rdfs:comment)."
> >>
> >> I think this is wrong, because it is not an instance, but a subclass. I
> >> reformulated that whole paragraph in the paper draft (but not yet in the
> >> spec):
> >>
> >> "DPV provides a list of suggested purposes which may be extended
> >> as shown in Listing ~\ref{lst:purpose-example} by subclassing existing
> >> purposes to create more specific ones: as regulations such as the GDPR
> >> generally require a specific purpose to be declared in an understandable
> >> manner, we suggest to such declare specific purposes as subclasses of
> >> one or several \texttt{dpv:Purpose} categories and to always declare the
> >> specific purpose with a human readable description (e.g., by using
> >> \texttt{rdfs:label} and \texttt{rdfs:comment})."
> >>
> >> This should also be changed in the spec.
> >>
> >> Likewise, the example in Listing 2 (Example 2 in the spec) uses
> >> instantiation instead of subclassing...
> >>
> >> :SomePurpose a dpv:Purpose ;
> >>         rdfs:label “Some Purpose” ;
> >>         dpv:hasSector dpv-nace:M72 .
> >>
> >> Isn't that also an error and should be subclassing?
> >>
> >>
> >>
> >>
> >> Axel
> >>
> >>
> >
> >
>

--
Javier D. Fernández García
jfergar83(at)gmail.com

Received on Sunday, 28 July 2019 18:52:08 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:27:57 UTC