Improve browsing through hierarchical resources

[herold]

Currently it's not possible to browse through/explore hierarchical resources (Collections), e.g. corpora and subcorpora or their constituent documents. This should be possible via CMDI's hasPart/isPartOf et al.

Update: the _isPartOf and _hasPart fields now provide this information.

Suggestion: records with _hasPart fields could be marked in the search result with a collection icon.

Original report by IDS:

Collecions und Teile der Collections werden nicht unterschieden [...] Das Korpus besteht aus mehreren Zeitschriften, die ihrerseits wieder aus mehreren Ausgaben bestehen (alles verknüpft in CMDI mit hasPart und isPartOf). Die Metadaten für die Zeitschriften sind nicht im VLO (wohl weil sie selbst keine "Ressourcen" haben, sondern nur auf die zugrundeliegenden Ausgaben verweisen). Die einzelnen Ausgaben sind im VLO, und werden über Volltextsuche (z.B. Titel) auch gefunden. Eine Exploration der Ressource über das VLO (z.B. von der Wurzel zu einzelnen Zeitschriften zu einzelnen Ausgaben ist derzeit nicht möglich).

[herold]

HZSK suggests to provide a way to not offer single corpus files as resources in the VLO at all even when there exists a metadata description for them.

Original report HZSK:

Wie unterscheiden wir zwischen Gesamtressourcen (etwa Korpora), die fürs facetted Browsen interessant wären, und Einzelressourcen (etwa “sessions”/”Kommunikationen”), die häufig nicht fürs Browsen oder auch als Suchresultat angezeigt werden sollen, weil es einfach zu viel davon gibt?

[haaf@bbaw.de]

remark from Florian Schiel: Improving the understanding of a MD record
When looking at the displayed MD fields in the VLO results the user cannot see that a record is in fact a part of a MD hierarchy. Usually the description does not say this, since the description within the MD record usually has a way to encode this dependency (and therefore it is in most times not repeated in the description).
At least for CMDI records there would a easy solution, by displaying the PID/URL list that is stored in the header element <IsPartOfList>, e.g.
<IsPartOfList><IsPartOf>​https://clarin.phonetik.uni-muenchen.de/BASRepository/Public/Corpora/ALC/ALC.2.cmdi.xml</IsPartOf></IsPartOfList>
Then the user could follow this link to see where the current MD recorded is is taken from.
If the element <IsPartOfList> is not contained in the header, we can assume that the record stands alone.

[schiel@bas.uni-muenchen.de]

The way 'downwards' into a hierarchy is even simpler: If the CMDI ResourceProxyList? contains links of type 'Metadata' they could simply be displayed in the resource page of the VLO together with the links to the resources (in analogy how Arbil does it). Then the user could see the contents of a hierarchical resource, and follow links to inspect MD of sub nodes.

[Twan Goosen]

Kees Jan no longer works on VLO. Assigning all VLO web app tickets owned by KJ to Twan

[Dieter Van Uytvanck]

Conceptually at least partially addressed by #750

[Twan Goosen]

Merged with #424

Remarks from that ticket:

---

schiel@…:

A large number of MD records shown in the VLO describe parts of a larger resource. In the CMDI this is expressed by the isPartof list in the header as well as ResourceProxyLinks? of type Metadata.
When the VLO displays such a MD record the user cannot see that it is a part of a larger hierarchy or has parts. The long term solution would be to render and present the header information, but since the isPartof list in CMDI is not well defined and the link types in the ResourceProxyList? vary, this may be not feasible on short term.

For the short term we suggest to set up 'normal' facettes in the VLO that harvest not from the header but from component elements that express the 'isPartof' / 'containParts' information in proper way to be displayed to VLO users (strings, names etc.).

Within this ticket centers may register XPAths / DC categories to
map for these two facettes.

BAS CMDI: isPartof
/CMD/Components/media-session-profile/media-session/Corpus/text()

DC-3944

BAS CMDI: containParts
<only available as Metadata links in ResourceProxyList?>

---

teckart:

Example resources for BAS:
containsParts: hdl:11858/00-1779-0000-001D-BE8B-7
isPartOf: hdl:11858/00-1779-0000-001D-B730-5

---

teckart:

Solution at IDS (Peter Fankhauser): 10932/00-01B8-B142-8832-9A01-6
Example: 10932/00-01B8-B142-8832-9A01-6

In our version of the OLAC-DcmiTerms? profile we allow for an attribute @ref
for some elements:

<isPartOf ref="clarind_ids_mkhz1_005717">Mannheimer Korpus Historischer Zeitschriften und Zeitungen</isPartOf>

This attribute refers to the corresponding ResourceProxy?:

<ResourceProxy? id="clarind_ids_mkhz1_005717">
<ResourceType? mimetype="application/x-cmdi+xml">Metadata</ResourceType?>
<ResourceRef?>​http://hdl.handle.net/10932/00-01B8-AE41-41A4-DC01-5</ResourceRef?>
</ResourceProxy?>

which gives the mimetype, the ResourceType?, and the actual pid of the resource.

While this indirection may seem a bit complicated, the overall approach has some
advantages:
(1) isPartOf, hasPart, isVersionOf, etc. are all already part of the OLAC-DcmiTerms? profile, so
there's no need to reinvent the wheel there
(2) The content of isPartOf can serve as anchor text, which is convenient for a human readable
interpretation.

---

twan.goosen@…:

Local uplinks and downlinks in record page (next to resources)

[teckart@informatik.uni-leipzig.de]

Support of Solr fields _isPartOf and _hasPart that only contain links to other resources in Solr (r6212:6214), fields contain Solr identifier (field id)

[Twan Goosen]

Update: the _isPartOf and _hasPart fields now provide this information

Suggestion: records with _hasPart fields could be marked in the search result with a collection icon (e.g. ​folder, ​package, ​archive or ​hierarchy?)

[Twan Goosen]

[6327:6332/vlo]: hierarchies now displayed in tree

[Twan Goosen]

[6333]: show 'uplinks' to all parents (there may be multiple)

[Twan Goosen]

If there are more than N parents for a record, show only the first N and provide a 'show more' or 'show all' link. N should probably be around 5~10.

[Twan Goosen]

Replying to twan.goosen@…:

If there are more than N parents for a record, show only the first N and provide a 'show more' or 'show all' link. N should probably be around 5~10.

Implemented this in [6346:6348/vlo/trunk/vlo-web-app].

In [6353:6358/vlo/trunk/vlo-web-app], also added upwards tree 'expansion' (setting tree root to one of the parents) dynamically.