Pith. sign in

REVIEW 3 major objections 6 minor 37 references

LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE

T0 review · 3 major / 6 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read A blockchain watchdog for data licenses logs every reuse

desk verdict A clean, honest architecture sketch whose core enforcement claim fails on the uncontrolled-client problem; useful as a design pointer, not as a result. read the letter →

arxiv 1908.02287 v1 pith:H2M25CPW submitted 2019-08-06 cs.DC cs.DB

Andine Havelange , Michel Dumontier , Birgit Wouters , Jona Linde , David Townend , Arno Riedl , Visara Urovi This is my paper · ORCID
classification cs.DCcs.DB
keywords blockchainsmartcontractsdatalicensingaccountabilityGDPRprovenanceCreativeCommonssharing
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

LUCE is a proposed blockchain-based platform for tracking what happens to a dataset after a researcher shares it. The paper aims to establish that license compliance can be managed automatically: each dataset is linked to a smart contract—an encoded agreement that runs on the blockchain—and the dataset itself is delivered inside a monitored executable that logs how it is used. The paper further claims this architecture can support the GDPR rights of access, rectification, and erasure, because records are kept on an immutable ledger and updates can be pushed to every known copy. If the design holds, researchers would have a technical reason to share data more freely, and data subjects would gain a practical way to exercise control over their personal records. This is presented as preliminary work, with a first smart-contract prototype rather than a deployed system.

What carries the argument

The central mechanism is the pairing of one smart contract per dataset with a monitored executable. The smart contract is a program stored on the Ethereum blockchain that holds the dataset's metadata, license, requester identities, purposes, and compliance status; it also controls the access-token lifecycle. The executable packages the dataset, the ccREL machine-readable form of the license, a license-monitoring submodule, and an update submodule; the update submodule sends compliance reports and log hashes to the smart contract on a timer. The access token, valid for a period T and renewable only when the contract judges the requester compliant, is the enforcement lever: losing the token means losing access. A separate modification module contacts all active copies when a data subject asserts rectification or erasure, so legal obligations reach every distributed copy.

What would settle it

Extract the dataset from the encrypted executable after decryption, use and redistribute it entirely outside the monitoring program, and then check the replicated event log: if no violation appears and the access token is still renewed, the central enforcement claim fails.

Watch

Extended reading notes

Core claim

The paper's central claim is that a per-dataset smart contract plus an encrypted executable can enforce data-license terms without a trusted third party. The executable contains the dataset, the machine-readable license, and a monitoring module; it logs uses and periodically reports compliance to the smart contract, which issues an access token valid for a fixed period and renews it only if the requester has complied. When a data subject requests access, rectification, or erasure, the data provider maps their ID to the dataset, the modification module instructs every active copy's monitoring module to update or delete the record, and the resulting transaction ID is stored as proof. In the paper's own description, this makes data accountability and license management automatic and distributed, and it is the contribution the authors put forward for data sharing and reuse.

Load-bearing premise

The load-bearing assumption is that the monitoring program running on the data requester's own computer faithfully detects and reports every use of the dataset and cannot be bypassed; the paper itself concedes it does not check whether the data are shared in another form.

Editorial extensions

If this is right

  • A data provider can audit reuse by reading the smart contract's recorded events instead of relying on the requester's promises.
  • A requester who breaks license terms loses token renewal and therefore loses access to the dataset at the end of the current period.
  • A data subject's rectification or erasure request propagates to every known copy through the modification module, and the transaction identifier doubles as proof for the subject and the supervisory authority.
  • Because the supervisory authority is a full node with access to replicated logs, GDPR oversight can be exercised without contacting each researcher individually.
  • Machine-readable license metadata in ADA-M profiles makes datasets discoverable and lets requested purposes be checked against the original collection purpose before access is granted.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Extension not developed in the paper: if the executable can be bypassed, the token-renewal mechanism becomes a public-commitment and audit tool rather than hard enforcement; combining it with remote attestation or trusted execution environments would close that gap.
  • Extension not developed in the paper: because the smart contract stores requester identity, purpose, and compliance status per dataset, the same records could be aggregated into a subject-facing dashboard, letting data subjects see all uses of their data through a single query to the supervisory authority; currently all subject requests flow through the data provider.
  • Extension not developed in the paper: the purpose recorded at request time could be used to generate machine-checkable purpose-compatibility proofs under the GDPR's secondary-use clause, not just as a human review step; the paper states compatibility checking but does not formalize the proof.
  • Extension not developed in the paper: the authors' planned behavioral evaluation could test whether the visible, public compliance checkpoint alone increases data-sharing willingness, independent of enforcement strength.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 6 minor

Summary. The paper presents LUCE, an early-stage blockchain-based architecture intended to manage data licensing and support GDPR compliance in scientific data sharing. The proposed design couples a per-dataset Ethereum smart contract with a data-requester-side executable that contains the dataset, a machine-readable license, and a monitoring module. The monitoring module is said to check compliance with the license, maintain a log of events, and periodically report hashes and replication identifiers to the smart contract; access tokens are renewed only if compliance is recorded. A separate modification module is intended to propagate data-subject rectification and erasure requests to all copies of the dataset. The paper includes background on blockchain, smart contracts, ccREL, and GDPR, a review of related provenance and DRM work, an architecture with sequence diagrams, and a minimal Solidity prototype. The authors describe this as preliminary work and state that a full implementation and evaluation are still needed.

Significance. If the described architecture worked as claimed, it would address a real and recognized problem: the lack of automated, auditable enforcement of data licenses and GDPR data-subject rights in scientific data reuse. The paper usefully identifies limitations of existing provenance-only or DRM-based approaches and proposes a concrete integration of Ethereum smart contracts with ADA-M metadata and ccREL licenses. However, the central contribution as stated—'automatic management and enforcement' of licenses and the ability to 'ensure subjects' GDPR rights'—is not supported by the design. The enforcement mechanism runs entirely on the data requester's machine and can be bypassed by reading the dataset outside the monitored executable, a gap the authors concede in Section 7. No evaluation, security analysis, or performance measurement is provided; the only concrete artifact is a minimal smart contract stub. The paper is honestly framed as preliminary work, but the abstract and Section 4 make claims that outrun what the architecture can deliver.

major comments (3)
  1. [§5.2.2, §7] The paper's central claim that LUCE 'automatically manages and enforces licensing terms' (Section 4) is unsupported because the monitoring module executes on the data requester's own machine. Section 5.2.2 states that the dataset is 'embodied in an executable, which is encrypted' and that the License-Monitoring sub-module 'continuously checks whether the actions performed by the data requester on the data comply with the licensing terms.' However, once the executable is decrypted, the requester controls the runtime and can extract the .cvs file or process it with external tools, none of which are observable by the monitor. Section 7 explicitly concedes: 'currently, do not check if the data are shared in another form (i.e by exporting the data into another format).' This is a load-bearing gap: the log, its hash, and the replication records are not reliable evidence of compliance, and token revocation only prevents future access to the executable, not continued use of extracted data. Without trusted execution, remote attestation, or a comparable guarantee, the enforcement claim collapses.
  2. [§5.3.2, §7] The claim that LUCE 'can ensure subjects' GDPR rights to access, rectification and erasure' (Abstract) is not substantiated. Section 5.3.2 describes how the modification module contacts monitoring modules in the executables and asks them to erase or modify a record 'from its own copy of the dataset.' This assumes that the only copies of the data are those inside the monitored executables, but the admitted export gap in Section 7 means requesters can hold unmonitored copies. The architecture therefore cannot ensure that erasure or rectification is propagated to all copies, and the blockchain transaction identifier only proves that the monitored executable was asked to make a change, not that the data is no longer present elsewhere. This weakens the GDPR guarantee from an actual assurance to a best-effort notification to cooperating requesters.
  3. [§6, §7] The manuscript provides no implementation evidence beyond a minimal Solidity prototype and no evaluation. Section 6 shows a prototype with functions publishDataset, addDataRequester, and renewToken, and states 'We are working towards fully implementing the LUCE platform.' Section 7 lists 'Evaluation' as future work, noting the need for 'technical feasibility and scalability' testing. Since the architecture's feasibility hinges on a monitoring module that can observe all relevant data uses, and since no adversary model or security evaluation is given, the paper is a design sketch rather than a demonstrated solution. This is acceptable for a position paper, but the abstract's definitive language overstates the maturity of the contribution.
minor comments (6)
  1. [§5.2.2] The phrase 'they cannot download the dataset alone' is misleading; the dataset is a .cvs file inside the decrypted executable, so after decryption the requester can read it directly. Consider rewording to say the dataset is bundled with monitoring tooling rather than implying copy protection.
  2. [§2.4] The description of GDPR actors is simplified; for instance, 'Data subjects can authorize a data controller' does not capture the legal roles precisely. The distinction between controller and processor could be tightened.
  3. [§4] There is a typo: 'is are currently not directly interacting' should be 'are currently not directly interacting.'
  4. [§5.2.2] 'the contracted identifier' should be 'the contract identifier.'
  5. [§6] There is a typo: 'this is due tot he fact' should be 'this is due to the fact.'
  6. [§7] The paper uses 'GDRP' once, which should be 'GDPR.' Also, 'i.e by exporting the data into another format' should be 'i.e., by exporting the data into another format.'

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: LUCE is an architecture proposal with no fitted quantities or derived predictions; its main weakness is unsupported client-side enforcement, not circular reasoning.

full rationale

This paper is an architecture/position paper. It contains no equations, no fitted parameters, no quantitative predictions, and no derivation chain whose output could be equivalent to its inputs by construction. The only self-citation is reference [8], a prior multiagent-system paper by some of the same authors, invoked in Section 5.2.1 only for the optional remark that 'further negotiations on the data can be set up at this stage as it has been discussed in [8]'. This is a background reference to an optional extension, not a load-bearing theorem, uniqueness claim, or ansatz, so it does not raise the circularity score. The paper's central claims that LUCE 'enforces' licensing terms and 'can ensure' GDPR rights to access, rectification and erasure are design assertions built on an encrypted executable containing a monitoring module; the known weakness is that the client-side monitor can be bypassed, and Section 7 concedes 'currently, do not check if the data are shared in another form (i.e by exporting the data into another format)'. That is a feasibility, trust, and security gap, not a circularity: the paper does not fit a parameter to data and then rename the fit as a prediction, nor does it define its target result into existence via a self-citation chain. Under the evidentiary bar of exhibiting a specific reduction, no circular step is present.

Assumptions & free parameters 0 free parameters · 6 assumptions · 3 invented entities

The paper introduces an architecture with no numerical fitting. Its central claims rest on strong domain assumptions about sharing whole datasets, uniform consent, and provider-controlled anonymization, plus an implicit trust assumption about the monitoring executable. These are listed in Section 5 and the conclusion.

assumptions (6)
  • domain assumption Assumption 1: Datasets are shared as a whole.
    The architecture restricts sharing to whole datasets and excludes partial access, simplifying the smart contract design. Stated in Section 5.
  • domain assumption Assumption 2: Dataset integration is not taken into account.
    Combining multiple datasets is explicitly out of scope. Stated in Section 5.
  • domain assumption Assumption 3: All records of data subjects in a dataset have given the same consent.
    Used to avoid per-subject consent handling. Stated in Section 5.
  • domain assumption Assumption 4: The license under which the dataset is shared is compatible with the consent of the data subjects.
    The paper says this is true in most research datasets, but offers no verification mechanism. Stated in Section 5.
  • domain assumption Assumption 5: Data records are anonymized and only the data provider can map a data subject to their records.
    This makes GDPR access/rectification/erasure possible through the provider, but the provider remains a single point of trust. Stated in Section 5.
  • ad hoc to paper The monitoring executable on the data requester's machine will accurately observe and report all data uses and cannot be bypassed or tampered with.
    Implied in Section 5.2.2; the dataset is delivered as an encrypted executable, but no evidence is provided that it is tamper-resistant.
invented entities (3)
  • LUCE platform
    purpose: Blockchain-based system for license accountability and GDPR compliance.
    Proposed in the paper as a new system; no independent validation or deployment.
  • Monitoring module
    purpose: Runs inside the encrypted executable to observe compliance and execute rectification/erasure updates.
    Only a design description is given; the paper says it 'needs to be further developed' in Section 7.
  • Replication module
    purpose: Stores copies of usage logs on random nodes off-chain for availability.
    Described at a high level; no implementation details provided.

how reviews work

0 comments
Cite this review

Pith. "Pith review of LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE." pith.science (2026). https://pith.science/paper/H2M25CPW

@misc{pith2026190802287,
  author       = {Pith},
  title        = {Pith review of: LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/H2M25CPW}},
  note         = {Machine review of arXiv:1908.02287}
}
read the original abstract

In this paper we present our preliminary work on monitoring data License accoUntability and CompliancE (LUCE). LUCE is a blockchain platform solution designed to stimulate data sharing and reuse, by facilitating compliance with licensing terms. The platform enables data accountability by recording the use of data and their purpose on a blockchain-supported platform. LUCE allows for individual data to be rectified and erased. In doing so LUCE can ensure subjects' General Data Protection Regulation's (GDPR) rights to access, rectification and erasure. Our contribution is to provide a distributed solution for the automatic management of data accountability and their license terms.

Figures

Figures reproduced from arXiv: 1908.02287 by the authors.

Figure 1
Figure 1. Connecting the data-sharing actors via blockchain 2.4 GDPR The new EU General Data Protection Regulation (GDPR) came into effect in May 2018 to extend the requirements of organiza￾tions in regards of collecting and processing personal data of EU residents [29]. Being a regulation, its rules are to be enforced in all EU member states. The GDPR also applies to non-EU organizations that collect and process EU residents… view at source ↗
Figure 2
Figure 2. LUCE Architecture requester is complying with the license when using the dataset and periodically reporting to the smart contract. Data providers using our solution must thus choose a license that is expressed in a machine-readable language. In our work we use the Cre￾ative Commons Expression Language (ccRELl) for monitoring licensing terms. 5. Architecture LUCE focuses on three main scenarios: sharing a dataset, re… view at source ↗
Figure 4
Figure 4. Accessing a shared dataset (simplified diagram) Request The data requester sends to the data provider a re￾quest for access including the dataset’s identifier, as well as the purpose for which they want to reuse it. In case the dataset con￾tains data related to data subjects, the purpose indicated by the data requester is checked against the initial purpose these data were collected for. In case both purposes are co… view at source ↗
Figures from the paper (7 more)
Figure 3
Figure 3. Figure 3: Sharing a dataset (simplified diagram) 5.2 Reusing a dataset The second scenario covers the case in which a data requester wants to reuse a shared dataset. This happens in two steps. The first is to access the dataset and the second is the monitoring of compliance with…
Figure 5
Figure 5. Figure 5: Monitoring compliance with the licensing terms [PITH_FULL_IMAGE:figures/full_fig_p007_5.png]
Figure 6
Figure 6. Figure 6: Complying with GDPR’s rights to access, rectification and erasure (simplified diagram) 5.3 GDPR compliance The third scenario our solution covers is the case in which a data subject exercises their right to access, erasure or rectification. How LUCE deals with this sce…
Figure 7
Figure 7. Figure 7: Smart Contracts defined in LUCE 7. Conclusion and future prospects In this paper, we presented LUCE, an architecture of a blockchain￾based solution for automatic data management of licensing terms and accountability in a GDPR compliant manner. LUCE en￾hances the possib…
Figure 8
Figure 8. Figure 8: Sharing a dataset: sequence diagram [PITH_FULL_IMAGE:figures/full_fig_p013_8.png]
Figure 9
Figure 9. Figure 9: Reusing a dataset: sequence diagram [PITH_FULL_IMAGE:figures/full_fig_p013_9.png]
Figure 10
Figure 10. Figure 10: Complying with GDPR’s rights to access, rectification and erasure: sequence diagram [PITH_FULL_IMAGE:figures/full_fig_p014_10.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

37 extracted references · 37 canonical work pages

  1. [1]

    Digital rights management-an overview of current challenges and solu- tions

    Alapan Arnab and Andrew Hutchison. Digital rights management-an overview of current challenges and solu- tions. In Proceedings of Information Security South Africa (ISSA) Conference, volume 2004, 2004. LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE — 11/14

    work page 2004

  2. [2]

    Empty archives

    Nelson B. Empty archives. Nature, 461:160–163, 2009

    work page 2009

  3. [3]

    Data sharing by scien- tists: Practices and perceptions

    Tenopir C., Allard S., Douglass K., Aydinoglu A.M., Wu L., Read E., Manoff M., and Frame M. Data sharing by scien- tists: Practices and perceptions. PLoS ONE, 6, 2011

    work page 2011

  4. [4]

    Borgman C. L. The conundrum of sharing data. Journal of the American Society for Information Science and Technol- ogy, 63:1059–1078, 2012

    work page 2012

  5. [5]

    Cardellino, C. (Inria). Licentia. http://licentia. inria.fr/. Accessed May 23, 2018

    work page 2018

  6. [6]

    https://creativecommons

    Creative Commons. https://creativecommons. org/. Accessed May 23, 2018

    work page 2018

  7. [7]

    Research Data - Practical challenges for researchers in data sharing [White paper]

    Stuart D., Baynes G., Hrynaszkiewics I., Allin K., Penny D., Lucraft M., and Astell M. Research Data - Practical challenges for researchers in data sharing [White paper]. https://www.springernature. com/in/open-research/open-data/ practical-challenges-white-paper , 2018. Retrieved May 22, 2018, from Springer Nature

    work page 2018

  8. [8]

    A multiagent system for dynamic data aggregation in medical research

    Alevtina Dubovitskaya, Visara Urovi, Imanol Barba, Karl Aberer, and Michael Ignaz Schumacher. A multiagent system for dynamic data aggregation in medical research. BioMed research international, 2016, 2016

    work page 2016

Show all 37 references
  1. [9]

    Elixir. Elixir. https://www.elixir-europe. org/, 2017. Accessed June 21, 2018

    2017

  2. [10]

    Licensing assistant

    European Data Portal. Licensing assistant. www.europeandataportal.eu/en/content/ show-license?license_id=CC-BY4.0. Ac- cessed May 23, 2018

    2018

  3. [11]

    Global Alliance for Genomics and Health

    GA4GH. Global Alliance for Genomics and Health. https://www.ga4gh.org/, 2019. Accessed June 21, 2019

    2019

  4. [12]

    ccREL: The Creative Commons Rights Expression Lan- guage

    Abelson H., Adida B., Linksvayer M., and Yergler N. ccREL: The Creative Commons Rights Expression Lan- guage. https://wiki.creativecommons.org/ images/d/d6/Ccrel-1.0.pdf, 2008. Accessed June 26, 2018

    2008

  5. [13]

    Open Data - The researcher perspective

    Leiden University’s Centre for Science and Tech- nology Studies (CWTS) and Elsevier. Open Data - The researcher perspective. https: //www.elsevier.com/about/open-science/ research-data/open-data-report , 2017. Retrieved May 22, 2018, from Elsevier

    2017

  6. [14]

    Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability

    Xueping Liang, Sachin Shetty, Deepak Tosh, Charles Kamhoua, Kevin Kwiat, and Laurent Njilla. Provchain: A blockchain-based data provenance architecture in cloud environment with enhanced privacy and availability. In Pro- ceedings of the 17th IEEE/ACM International Symposium on...

    2017

  7. [15]

    Blockchain technology: principles and appli- cations

    Pilkington M. Blockchain technology: principles and appli- cations. In Olleros F.X. and Zhegu M., editors, Research handbook on digital transformations , chapter 11, pages 225–253. Edward Elgar, Oxford, 2016

    2016

  8. [16]

    Bitcoin: A peer-to-peer electronic cash system

    Satoshi Nakamoto et al. Bitcoin: A peer-to-peer electronic cash system. 2008

    2008

  9. [17]

    Biomedical Data Translator.https://ncats

    National Center for Advancing Translational Sciences (NCATS). Biomedical Data Translator.https://ncats. nih.gov/translator, 2018. Accessed June 21, 2018

    2018

  10. [18]

    Data Commons Pi- lots

    National Institutes of Health (NIH). Data Commons Pi- lots. https://commonfund.nih.gov/commons,

  11. [19]

    A blockchain-based approach for data accountability and provenance tracking

    Ricardo Neisse, Gary Steri, and Igor Nai-Fovino. A blockchain-based approach for data accountability and provenance tracking. arXiv preprint arXiv:1706.04507 , 2017

    2017 arXiv

  12. [20]

    Ocean Protocol:A De- centralized Substrate for AI Data and ServicesTechni- cal Whitepaper

    Ocean Protocol Foundation. Ocean Protocol:A De- centralized Substrate for AI Data and ServicesTechni- cal Whitepaper. https://oceanprotocol.com/ tech-whitepaper.pdf. Accessed May 18, 2019

    2019

  13. [21]

    https://opendatacommons

    Open Data Commons. https://opendatacommons. org/. Accessed May 23, 2018

    2018

  14. [22]

    Using blockchain and smart contracts for secure data provenance management

    Aravind Ramachandran, Dr Kantarcioglu, et al. Using blockchain and smart contracts for secure data provenance management. arXiv preprint arXiv:1709.10000, 2017

    2017 arXiv

  15. [23]

    Consent codes: upholding standard data use conditions

    Dykeand S., Philippakis A., De Argila J., Paltoo D., Luetke- meier E., Knoppers B., Brookes A., Spalding J.D., Thomp- son M., Roos M., et al. Consent codes: upholding standard data use conditions. PLoS genetics, 12(1):e1005772, 2016

    2016

  16. [24]

    and Kalinov V

    V oshmgir S. and Kalinov V . Blockchain Handbook: A Beginners Guide. https://s3.eu-west-2. amazonaws.com/blockchainhub.media/ Blockchain+Technology+Intro.pdf, 2017. Accessed June 26, 2018

    2017

  17. [25]

    What is Blockchain Technology? How Blockchain Works.https://www.edureka.co/ blog/how-blockchain-works/, 2018

    Shashank (edureka!). What is Blockchain Technology? How Blockchain Works.https://www.edureka.co/ blog/how-blockchain-works/, 2018. Accessed June 26. 2018

    2018

  18. [26]

    Smart contracts: building blocks for digi- tal markets

    Nick Szabo. Smart contracts: building blocks for digi- tal markets. EXTROPY: The Journal of Transhumanist Thought,(16), 18, 1996

    1996

  19. [27]

    European Open Science Cloud

    The European Commission. European Open Science Cloud. https://ec.europa.eu/ research/openscience/index.cfm?pg= open-science-cloud, 2018. Accessed June 21, 2018

    2018

  20. [28]

    http://reusabledata

    The (Re)Usable Data Project. http://reusabledata. org/. Accessed May 23, 2018

    2018

  21. [29]

    European Union. Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of LUCE: A Blockchain Solution for monitoring data License accoU...

    2016

  22. [30]

    The legal framework for reproducible scientific research: Licensing and copyright

    Stodden V . The legal framework for reproducible scientific research: Licensing and copyright. Computing in Science & Engineering, 11(1):35–40, 2009

    2009

  23. [31]

    The open dig- ital rights language (odrl) vocabulary and expression 2.2

    World Wide Web Consortium (W3C). The open dig- ital rights language (odrl) vocabulary and expression 2.2. https://www.w3.org/TR/odrl-vocab/,

  24. [32]

    Ethereum: A secure decentralised generalised transaction ledger, 2015

    Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger, 2015

    2015

  25. [33]

    Accessed June 26, 2018

    2018

  26. [34]

    Multi- media security technologies for digital rights management

    Wenjun Zeng, Heather Yu, and Ching-Yung Lin. Multi- media security technologies for digital rights management . Elsevier, 2011

    2011

  27. [35]

    automatable discovery and access matrix

    J Patrick Woolley, Emily Kirby, Josh Leslie, Francis Jean- son, Moran N Cabili, Gregory Rushton, James G Hazard, Vagelis Ladas, Colin D Veal, Spencer J Gibson, et al. Re- sponsible sharing of biomedical data and biospecimens via the “automatable discovery and access matrix”(ad...

    2018

  28. [37]

    LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE — 13/14 Figure 8

    Appendix The following figures show respectively the detailed sequence diagrams for: (i) Sharing a dataset Fig:8; (ii) Re-using a dataset Fig:9 and (iii) Complying with GDPR Fig:10. LUCE: A Blockchain Solution for monitoring data License accoUntability and CompliancE — 13/14 Fi...

  29. [2018]

    Accessed June 21, 2018

    2018

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.