solid / solid/data-interoperability-panel
Data registration vs. container
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 58
- Forks
- 18
- PR merge metrics
- No merged PRs in 30d
Description
From the definition of the Data Registration, it would seem that the registration itself is the container in which its shapetree-adhering instances are stored. After all, it has a number of metadata predicates (relevant agents, timestamps etc.), but none that points to a container.
Am I right in this assessment, and (if so) why is that the case?
It seems to preclude a division of responsibility, e.g., where I keep my registration metadata on one host, and have it point to my data on another. At first I thought maybe the idea is to have the RS use it for knowing which shapetree a container has to adhere to, but then this would seem to conflict with the idea of "planting trees" from the ShapeTrees spec.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the Data Registration definition and the ShapeTrees specification, especially the references to containers, metadata predicates, and “planting trees.” Done means the specification clearly explains whether a registration is itself a container, how data may be hosted separately, and how shape-tree responsibility is assigned.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100