- From: Harshvardhan J. Pandit <me@harshp.com>
- Date: Mon, 13 May 2019 12:48:54 +0100
- To: "Ekaputra, Fajar Juang" <fajar.ekaputra@tuwien.ac.at>
- Cc: "Kiesling, Elmar" <elmar.kiesling@tuwien.ac.at>, Data Privacy Vocabularies and Controls Community Group <public-dpvcg@w3.org>
Hi Fajar, all. On 13/05/2019 09:26, Ekaputra, Fajar Juang wrote: > (1a): As you suspect, we don’t have these descriptions elsewhere, so we > need to define them anew - would be happy to work together with > you/elmar/others on these descriptions. Okay, so let's just start filling in the descriptions. > (1b): If I remember it correctly, the creation of this class is the > result of the discussion last Tuesday. > However, I agree with your argumentation line that probably it’s better > to remove it or even make it into a property (as originally proposed). I think the argument for having it as a class was to allow the flexibility to combine it with another class to say this is always derived (for a particular use-case). For example, in an organisation, the user's likes may always be derived, in which case, they could create a class called DerivedLikes by subclassing both Likes and Derived. -- --- Harshvardhan Pandit PhD Researcher ADAPT Centre Trinity College Dublin
Received on Monday, 13 May 2019 11:51:14 UTC