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

Reusing properties within a template #3535

Open
olufine opened this issue May 10, 2022 · 1 comment
Open

Reusing properties within a template #3535

olufine opened this issue May 10, 2022 · 1 comment

Comments

@olufine
Copy link

olufine commented May 10, 2022

Currently it is not allowed to resuse a property in the same template, unless the different occurrences are connected to nested templates instantiating different classes. This leaves a gap for the need of using the same property both for literal values and for uri/ookups.

Example:
In property templates for the http://rdaregistry.info/Elements/w/P10256 ("has subject") property, we would like to specify that both certain controlled term lists (not LD, so no URIs) as well as certain URI lookups are allowed as value sources.
This would be OK if we could specify 2 occurrences of the property, as literal and uri/lookup, respectively. Is there any problem with allowing that?

@michelleif
Copy link
Contributor

The problem with allowing more than one property template to have the same property is that when Sinopia displays a resource, it doesn't know which field to display each object in, since both fields will have the same property -- more detail here

But as explained in the page linked to above, there are several disadvantages, including the one you just raised (which I should add to the page!) So this is something to look into in our next work cycle.

In fact, Sinopia used to allow a field to accept either a URI or a literal, but this became problematic, details here: #2887

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