Re: Contract

Hi. Thanks.
I went through the documentation and github RDF - and I think the FIBO 
contract terms are a better fit for abstract/general contracts.

Of interest from ePO is the link to legislative requirements and the 
'Criterion' concepts. These might be useful for data sharing agreements 
and such - but I need to take a more detailed look at it.

Regards,
Harsh

On 06/11/2023 08:07, Bert Van Nuffelen wrote:
> Hi Harsh,
> 
> As you point out, the contractual part is mainly the result of a tender.
> Nevertheless it might be of interest to have a look at the terms 
> mentioned, as they might coincide with other kind of contracts.
> 
> 
> kr,
> 
> Bert
> 
> ------------------------------------------------------------------------
> *From:* Harshvardhan J. Pandit <me@harshp.com>
> *Sent:* Friday, 3 November 2023 18:19
> *To:* Bert Van Nuffelen <Bert.Van.Nuffelen@tenforce.com>; Tek Raj 
> Chhetri <tekrajchhetri@gmail.com>; public-dpvcg@w3.org <public-dpvcg@w3.org>
> *Subject:* Re: Contract
> Hi Bert.
> Good point/reference - can we use the eProcurement ontology for
> service/consumer contracts as well?
> I know it is based on the tendering process but not sure if it has
> concepts to also model B2C contracts.
> 
> Regards,
> Harsh
> 
> On 03/11/2023 17:03, Bert Van Nuffelen wrote:
>> Hi,
>> 
>> on contracts, I would also consult the eProcurement Ontology: 
>> https://eprocurementontology.github.io/#contrac 
> <https://eprocurementontology.github.io/#contrac>
>> <https://eprocurementontology.github.io/#contract 
> <https://eprocurementontology.github.io/#contract>>t
>> 
>> kr,
>> 
>> Bert
>> ------------------------------------------------------------------------
>> *From:* Harshvardhan J. Pandit <me@harshp.com>
>> *Sent:* Friday, 3 November 2023 17:57
>> *To:* Tek Raj Chhetri <tekrajchhetri@gmail.com>; public-dpvcg@w3.org 
>> <public-dpvcg@w3.org>
>> *Subject:* Re: Contract
>> Hi Tek.
>> Thanks for sharing this. I have made comments in the spreadsheet itself.
>> 
>> More thoughts on the modelling of contracts under DPV:
>> 
>> 1) DPV should prefer normative terms where possible (where normative
>> means as it is legally enforceable). In this case, it would be contract
>> law which I know little about. I presume SmashHit as a project had the
>> necessary legal expert involvement for their use-cases, but I'm not
>> quite sure the definitions in the document are generalised enough for DPV.
>> 
>> Do we have a legal expert who can sanity check this for DPV?
>> 
>> 2) FIBO and GIST specifically model business contracts (SmashHit
>> ontology references FIBO) and have ability to express relevant
>> information such as contract categories, parties, elements of a
>> contract, and specific relations such as "has contract party", "has
>> contractual element", and "has effective date". See
>> https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/Contract <https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/Contract> <https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/Contract <https://spec.edmcouncil.org/fibo/ontology/FND/Agreements/Contracts/Contract>>
>> 
>> Can we reuse these? IF not, then why not? I see similar concepts in the
>> proposed set but with different definitions. I presume FIBO and GIST are
>> "normative" in their concepts and definitions given their background.
>> 
>> For the scope of this concept, DPV should only provide 'metadata' about
>> the contract, including limited content such as what personal data is
>> involved, which service, purpose, etc. We should NOT be aiming to write
>> a full legal agreement / contract using DPV. Should we point to FIBO for
>> contract information and ODRL to express contents of a contract?
>> 
>> 3) DPVCG's (and DPV's) scope is to have contract be the legal basis for
>> processing of personal data (DGA has non-personal data contracts, which
>> should be expressed as a concept separately). So the contract categories
>> should be a reflection of this category of use-cases similar to how
>> consent is categorised based on the requirements (informed, explicit).
>> 
>> As I said earlier, I'm a blank for contract law. But I'd like to see
>> aspects such as whether the contract was drafted by a service provider
>> and accepted by consumer (with no negotiation), or whether the contract
>> was a 2-party agreement e.g. both controller and data subject involved.
>> Such categorisation should help in interpreting and applying the
>> contract - just like with consent types we identify requirements for
>> "valid consent".
>> 
>> 4) Contract as a legal basis can also be B2B e.g. data controller and
>> third party (thanks to Jan for asking about this). Should this be in the
>> scope of DPV? IMHO - no because it is a separate domain/use-case though
>> DPV can help express its contents (e.g. purpose, TOMs).
>> 
>>   From a EU-centric view we have GDPR Art.6-1b state "contract to which
>> the data subject is party" as the legal basis and not just a "contract".
>> So my suggestion is that DPV's (personal data) contract MUST be with the
>> data subject as a party.
>> 
>> NOTE: contract between controller and processor is not covered under
>> legal basis, but under organisational measure even if it is a "legal
>> basis" from the processor's POV. Same for controller and third party.
>> 
>> 0) With this discussion under way, we have other legal basis that also
>> need similar information - using GDPR Art.6-1 list:
>> a) consent - done
>> b) contract - ongoing
>> c) legal obligation - none
>> d) vital interests of person - none
>> e) public interest - none
>> e) official authority - none
>> f) legitimate interest of controller - none
>> f) legitimate interest of 3rd party - none
>> 
>> We also have DGA's legal basis, which include "donated data" type
>> scenarios for altruistic purposes (which AFAIK fit e) public interest).
>> 
>> Regards,
>> Harsh
>> 
>> 
>> On 03/11/2023 15:27, Tek Raj Chhetri wrote:
>>> Dear all,
>>> 
>>> I am writing to share the contract related vocabularies from the 
>>> smashHit project to be integrated into DPV. I had shared it with Harsh 
>>> and there're comments, which I will be fixing soon. In the meantime, if 
>>> there're any further comments, you can directly make a comment.
>>> 
>>> Link: 
>>> https://docs.google.com/spreadsheets/d/1-whatFmVqP0XkSp90p_KsGN82TQ3h6CgA8zDSHk92kg/edit?usp=sharing <https://docs.google.com/spreadsheets/d/1-whatFmVqP0XkSp90p_KsGN82TQ3h6CgA8zDSHk92kg/edit?usp=sharing> <https://docs.google.com/spreadsheets/d/1-whatFmVqP0XkSp90p_KsGN82TQ3h6CgA8zDSHk92kg/edit?usp=sharing <https://docs.google.com/spreadsheets/d/1-whatFmVqP0XkSp90p_KsGN82TQ3h6CgA8zDSHk92kg/edit?usp=sharing>> <https://docs.google.com/spreadsheets/d/1-whatFmVqP0XkSp90p_KsGN82TQ3h6CgA8zDSHk92kg/edit?usp=sharing >
>>> 
>>> Thank you.
>>> 
>>> Best,
>>> Tek
>> 
>> -- 
>> ---
>> Harshvardhan J. Pandit, Ph.D
>> Assistant Professor
>> ADAPT Centre, Dublin City University
>> https://harshp.com/ <https://harshp.com/> <https://harshp.com/ 
> <https://harshp.com/>>
>> 
> 
> -- 
> ---
> Harshvardhan J. Pandit, Ph.D
> Assistant Professor
> ADAPT Centre, Dublin City University
> https://harshp.com/ <https://harshp.com/>

-- 
---
Harshvardhan J. Pandit, Ph.D
Assistant Professor
ADAPT Centre, Dublin City University
https://harshp.com/

Received on Monday, 6 November 2023 13:38:56 UTC