I am not a lawyer. But I would like a few simple choices for the terms by which I share my data, which may depend on the context (data type/application/etc). What are the default terms, what are the challenges, and what is Solid’s role in helping user’s navigate the terms by which I make my data available?
Thanks,
Rick
Perhaps “what is an atomic Solid element” could help you
Being a chemist, those terms likely mean something entirely different to me. But I trust that I need to spend some time reading the documentation. Thanks for your response.
I’m having trouble finding “atomic solid element” in the documentation. Where is the documentation that explains how users negotiate/ or control licensing terms wrt their data? Thanks.
I think it refers to another post on the forum: What is the "atomic element" of SOLID?
Yes forgotten the link 
but that’s only my point of view.
Lot’s of new question, for example:
Technically, An app can create pods, so can an app be the owner of the data on that pod? What if that data is created by another app? 
Access control is important. But my question remains, how can a pod owner assign licensing terms to his shared data? Traditionally, the application owner sets the terms of use of the service and how it will use the data. I’d like to see control of licensing and terms of use return to the data owner.
If the Solid specifications would include a set of standard licensing choices for data use, then the application providers would be incentivized to work within that framework. Give pod owners a choice of several popular licensing options that would be applied in any instance of sharing data. I am certain this would be a difficult and contentious issue, but well worth implementing if it can return control of data to the owners.
There are things like the “Open Digital Rights Language” being worked on, which may apply in this area:
https://www.w3.org/TR/odrl-model/
Because access control in SOLID (and really at Linked Data and really web level) is at the granularity of files / documents (not fragments of files / documents), then it may or may not make sense for digital rights to be applied at same level.
So it could also appear to be possible / feasible to grant a person or app or etc access to a file or folder on your SOLID Pod, which would then contain embedded / inline or as a separate file containing descriptions of other files / folders specific digital rights.
And I agree, access control is not the same as digital rights, and GDPR type concerns regard digital rights, not mere access control.
Being granted actual access to digital resources (such as even a public file / folder within a SOLID Pod) does not imply digital rights of any kind … and similarly just denying access to any file or folder also does not imply any digital rights.
ACL being access control, not Digital Rights.
So similar to a Github repository, and files and folders within, there needs to be specific licensing information made available for the contents.
This can done however the owner wants, but would certainly be valuable to describe in RDF (using something like ODRL possibly).
a problem im seeing across the board seems to be tight coupling of SOLID spec level things with implementation / app level things regarding the granularity of URIs (resources) and triples and graphs and then files and folders and pods … specifically regarding encryption and access and authorization and etc …
i cant understand why “files” (with specific file extensions) and “folders” are a part of the base SOLID spec and implementation .
essentially, the runtime design patterns are forced to end up being “turn database rows into individual files” and “create a folder for each app”, etc …