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

labels #146

Open
trondaal opened this issue Mar 6, 2019 · 1 comment
Open

labels #146

trondaal opened this issue Mar 6, 2019 · 1 comment

Comments

@trondaal
Copy link

trondaal commented Mar 6, 2019

Hi,

The various labels in the RDA vocabulary are very useful, but it is also something that potentially can be improved. The English labels are very ‘precise’, but they also have rather limited use because many are too long and contains terms that will be redundant if used in a real-world application. Some translated labels are short, maybe because they are based in earlier versions of the vocabulary. Particularly the properties for ‘relationships’ tend to get complex because the label is used to describe meaning, direction, domain and range. Some labels end up as constellations of terms that make little sense as individual sentences.

To be precise: the reuse value of the labels in the vocabulary is rather limited. If I were to use the RDA vocabulary in my own system, I probably would have to delete all existing labels for all languages and create new ones that are designed according to the needs of the target system.

The main purpose of a label is to provide a human readable representation, but what is a convenient, readable and comprehensible label will depend on the context the label is intended for. On a web page presenting the concept, such as the RDA Registry site, we may prefer labels that are precise and with some details and it does not really matter if the label gets long. Even labels that end up as rather meaningless sentences such as “has person member of corporate body” are acceptable because we interpret the label in the context of other information on the page. On the other hand, if labels are to be used in a visualization such as the text displayed at the edges of a graph or labels are used as a prefixes when listing up the properties of an instance in a list-based display, we need shorter/compact labels. In such contexts, terms that indicates the direction may not needed (has, is, of etc.), and surely, we do not need the domain and range types. Instead of «has person member of collective agent" we may only want a label saying “member” or “member of”. Current labels in use include: rdfs:label, skos:altLabel, rda:toolkitLabel. Unfortunately, they all are based on the same ‘design’.

Is it possible to consider restricting one of these label types to “short form labels”, or maybe create a special label-property in the registry namespace for short/compact labels? Many are contributed with translations to the vocabulary and labels potentially have a very high reuse value beyond presenting the schema e.g. for multi-language presentation of RDA data in search systems and knowledge bases.

Regards,
Trond Aalberg
Oslo Metropolitan University

@RDATech
Copy link

RDATech commented Oct 28, 2020

The labels used for RDA elements are not intended for consumption by end-users.

The labels must be unique across all elements, for human distinguishability and as a reminder of the semantics embodied in the RDF representation and the element definition. They must also be unique because they are used as a substitute for the element IRI in some non-linked-data implementation scenarios (particularly MARC 21).

The issue of providing labels for end-user display has been under discussion for many years. We have considered:

a) adding a label subtype to the element that can store a 'user-friendly' label.
b) substituting a label from the unconstrained element set using a lookup table.
c) creating a separate lookup for 'user-friendly' labels.

The problem with all 3 solutions is that there is no agreement across RDA user communities as to what the 'user-friendly' label should be. Option a) requires agreement across international communites that is not likely to be achieved. Option b) was investigated by the North American RDA Committee over the past year, and has now been rejected as a suitable resolution. Option c) is the only feasible way forward, but each RDA community will need to develop its own agreed labels.

So this is really a localization issue that cannot be resolved at global level.

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