Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce different storage types #377

Open
elf-pavlik opened this issue Jan 26, 2022 · 1 comment
Open

Introduce different storage types #377

elf-pavlik opened this issue Jan 26, 2022 · 1 comment

Comments

@elf-pavlik
Copy link
Member

This possibility would be similar to one taken in Solid Notifications Spec

Personally, I would like to see at least 2 different storage types defined

  1. Hierarchical storage where current IRI / semantics would be moved to.
  2. Opaque storage where resources would have IRI opaque to the client and containment would only rely on ldp:contains statements in (meta)data.

I think having different storage types would save us from boxing the whole ecosystem in one of those approaches. Valid arguments can be made for both approaches. Instead of us trying to decide which arguments are 'more valid', having different storage types would allow the ecosystem to choose one more appropriate for a given situation.

@woutermont
Copy link
Contributor

woutermont commented Jul 7, 2023

Quite a strong objection to the idea of separating hierarchical and non-hierarchical organizations as different storage types.

  • It would mean I cannot store resources organized in different ways on the same storage.
  • Organization style is just one aspect of storage/resources that can differ (orthogonally). Using types to distinguish between more than one or two aspects at the same time is very unpractical on such a coarse level.
  • The main reason hierarchical storage is "a thing" is because some people want to afford it special syntax (i.e. slashes), rather than using rdf metadata to transfer the necessary semantics. Apart from that (which should be avoided), differences between organization style can perfectly well be handled by different metadata on a resource-level.
  • If we really want to keep it, URI path segments form an acceptable way of communicating hierarchy; non-hierarchical resources can then be identified using single-segment URIs with query parameters.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants