Proposal: Containment chain auxiliary resource

[damooo]

In many cases, There exists natural requirement of knowing and or showing containment chain, like in breadcrumbs, etc.

Currently it is not possible, in single request. Though uri semantics can give hint, they are only necessary condition, rather than sufficient to establish containment fact (As we cannot know at which slash storage root starts, and whether given resource is auxiliary).

On file systems, it is possible to show such, as root is known, and no non-contained resources exist there.

Proposal is to have a hierarchy chain resource or a prov-chain resource as auxiliary resource to every resource, whose content is purely server managed.

It will return entire hierarchy chain, (aux chain too?), in single request. It will be inline with linked data principles too to derive hierarchy from links, rather than uri string manipulation. And enables getting better navigation and context about any solid resource.

[kjetilk]

Actually, I'm not sure I am on board with this, though I would like to have an extensible aux resource system where such things could be expressed.

The bigger issue here is really the knowledge organization system that people need to build on the top of Solid. There is a tendency to put too much of knowledge organization into the containment hierarchy. I think that's bad, and something that should be discouraged. Hierarchies are bad for knowledge organization, and the static nature of URIs would invariably create problems too.

Basing breadcrumbs on the containment hierarchy would further lure people into thinking it is a good idea to overload the containment hierarchy with further interpretation.

Instead, people should use for example SKOS as part of their data, and then derive knowledge organization, including possibly breadcrumbs in applications, from the optional hierarchy that can be expressed in SKOS.

[damooo]

@kjetilk , indeed, hierarrchies will be bad for knowledge organization.

But, this case doesn't actually comes under "knowledge organization", instead comes under "document organization". Though there may not be clear line between two, knowledge organization involves organizing descriptions about both concept resources and information resources, where as document organization purely deals with organizing documents. We can see this in introduction to SKOS too:

SKOS—Simple Knowledge Organization System—provides a model for expressing the basic structure and content of concept schemes such as thesauri, classification schemes, subject heading lists, taxonomies, folksonomies, and other similar types of controlled vocabulary.

And solid for sure recommends meronomy as basic document organization principle. (Which can be augumented with free links too, of course)

And we are also thinking of collaborative knowledge management system lie wikidata built on top of solid. Where each resource (concept/information) has it's corresponding unique solid rdf source containing it's authoritative description. In this case we actually want purely flat set of documents corresponding to flat set of described subject resources, with out any fixed organization scheme. And this case requires robust pagination support too.

But above mentioned case is for other purposes, where one uses it for document organization like file system, and other mundane applications. It will ease developers if efficient support for document meronomy is provided, as solid/ldp puts high emphasis on document containment.

[damooo]

In other words, there may not be much issue in organizing documents in hierarchies, until free form linking also supported (As is natural on web. And already recommonded by solid through containers.). Where as the "content/description" in those documents must not emphasise hierarchical organization of concepts they are "describing".

The distinction between organization scheme of documents, and organization scheme of knowledge in those documents may be useful.

[kjetilk]

Right, but I feel that document organization should just be a subcase of knowledge organization.

To me, I don't think this is so much of a spec-level issue (though, it might be if it is insisted on a server-managed resource), but most certainly we will need to provide guidance on how to build knowledge organization on Solid, but that feels more like a best practice issue than a spec issue.

Nevertheless, let us keep this issue open so that it can be revisited once we have an generic way to provide auxiliary resources.

[damooo]

Right, but I feel that document organization should just be a subcase of knowledge organization.

Indeed.. But there is subtle difference.

If resources are used for representing description of entities of other world of discourse, server only provides mechanism to manage description, but doesn't offer any interaction model to alter that world of discourse itself. For example, if server used to record description of geo-political entities, It can at max provide interaction model to mutate those descriptions, and restrict ontology of description. But cannot provide any interaction model to alter real geo-politics, neither it can constrain any happenings in geo-politics, and is not responsible to state of world.

Where as, for this case, the world of discourse is "set of electronic documents in that server, and their behaviour". And server itself provides interaction model to alter it, and constrain it, And is directly responsible for that world.

The fact that it also provides description of that world is orthogonal to interaction model, though coupled because of self-describing information resources. Server managed triples is just disguise to this coupling.

Here proposal is to provide convenient extension of interaction model to world-of-discourse server is responsible for, to ease navigation as in #400. Not to change ontology of description. ontology is already hierarchical through ldp:contains, as world of discource (like containers), and interaction model defined (POST to containers, etc..), are hierarchical.

[woutermont]

@damooo, I find your characterization of the dual nature of Solid quite good, but I must agree with @kjetilk that we should refrain ourselves from all too eagerly providing special affordances to specific forms of knowledge organization.

Solid servers manage both data and metadata about that data. Sometimes, the data will be ordered hierarchically, and will have related containment metadata (e.g. prof P. is a member of faculty F.). Sometimes, in a subset of the hierarchical cases, the data will be a document (e.g. document D. is a member of collection C.). But sometimes, it will be neither (e.g. My name is Wouter Termont). The key take-away is that in specifying the constraints of Solid, we should take into account all cases equally, and allow all kinds of affordances to be constructed on a higher level, rather than making special affordances for specific cases on the lower level.

---

[In particular, I have never been fond of our focus on a narrow interpretation of slash semantics and the hard link we made with LDP containment. Set-theoretic membership is much more broadly useful (e.g. prof P. is a member of faculty F. but also of motor club M.; document D. is member of the Solid CG reports, but also of P's students' mandatory reading list). But that is an aside.]