Open WilliamChelman opened 12 months ago
Linked to #29 I believe, even though scopes are not entirely the same, as here the tree view would be limited to the defined boundaries, but nothing tells it if some property should or should not be used in the tree (for example in the 2nd screenshot above, it could make sense to hide skos:inScheme
in the tree)
When generating the form of "something", it could be useful to define where to start and where to stop when pulling data to be edited, considering that we are not limiting things to one given node or embedded forms. So the idea would be to define the boundaries of a data graph being loaded, ideally independent of the use of named graphs. For a more concrete example, I'll take the example of a form generated to be able to edit a
skos:ConceptScheme
and all theskos:Concept
within.Defining starting point(s) / root(s)
In the context of this application,
skos:ConceptScheme
are defined as "roots", and so whenever a user would land on the form of askos:Concept
, it would always be in the context of itsskos:ConceptScheme
, as reflected in the tree view on the left.For now in this app, the solution we use is something that looks like this
Defining external boundaries
When going deeper, the tree can expand through any property, like
skos:narrower
and the likes This makes sense as narrowers are conceptually part of the sameskos:ConceptScheme
, and so editing them in the same context/data graph feels logical. But let's imagine ash:PropertyShape
forskos:exactMatch
. It could look like thisNormally,
skos:exactMatch
should point to askos:Concept
that belongs to an otherskos:ConceptScheme
. So if we had something likeex:Belgium skos:exactMatch otherDomain:be
, thatotherDomain:be
node should not be pulled as part of theskos:ConceptScheme
form whereex:Belgium
belongs to.For now in our app we made use of something that looks a bit like this
hanami:linkingStrategy
being[0..n]
and only used in shapes withsh:nodeKind
beingsh:IRI
orsh:BlankNode
. Here is a revised version of what we use, as some of them are more specific than this use-case:hanami:ExternalReferenceLinkingStrategy
: defined as an external node, so its metadata will not be editable within the context of the form generated trough this shapes graph. It's only possible to add/remove references trough such property.hanami:CreateLinkingStartegy
: default value if none is given. If some "add" button is clicked linked to this property, a new node would be created with its dedicated formhanami:InternalReferenceLinkingStartegy
: the user is prompted to select another node within the same data graph instead of creating a new one.The 2 last options are sometimes used together, as one of our client needed to cleanup their concept hierarchy, and so
hanami:CreateLinkingStartegy
andhanami:InternalReferenceLinkingStartegy
were both set on most hierarchical properties (skos:hasTopConcept
,skos:narrower
, etc.)