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

Determine customization possibilities for models #10

Open
azaroth42 opened this issue Nov 11, 2015 · 4 comments
Open

Determine customization possibilities for models #10

azaroth42 opened this issue Nov 11, 2015 · 4 comments
Labels

Comments

@azaroth42
Copy link
Contributor

Responsible: @azaroth42 @no-reply @mjgiarlo @hannahfrost @guegueng
Accountable: @mjgiarlo @hannahfrost
Consulted: ?
Informed: Directors

Issue:
There should be a lightweight way to customize models provided in HyBox. If no customization is possible, then the risk is that adopters will turn away from the product for the wrong reasons. For example, if the would-be adopter "needs" to have a certain metadata field, but there is no possibility of adding additional fields, then that might be considered a deal-breaker. The decision to be made is the extent to which customization of models is to be implemented, from a documented set of choices with advantages and likely costs/risks.
The subsequent side of this is that the information needs to be exposed to the end user in a reasonable way.

Proposal:
Responsible to discuss and document decision on most appropriate way forwards, taking into account cost to implement. Initial strawperson list to discuss and extend:

  • No customization
  • Create hyboxlocal namespace and shove everything in there
  • Selection from a long list of pre-determined predicates / options
  • JSON-LD contexts to perform mappings only in JSON input
  • Allow assignment of human readable label to mapping
  • Allow creation of terms, labels/templates, and expression of equivalence to external
  • Allow full on ontology modeling
@azaroth42
Copy link
Contributor Author

Ping @hannahfrost @mjgiarlo @anarchivist.

I think we can defer this, as whatever the answer is, it has no effect (as far as I can tell) on current efforts. It could play into a discussion around admin configuration and UI design but we can assume there will always be things that people will want to add, and the core model should cover the core requirements, no everything. If you think we should tackle it, please take off the defer label.

@anarchivist
Copy link
Member

👍

@hannahfrost
Copy link

👍 to deferring for the time being. I added @guegueng as a Responsible and it would be helpful to start discussions on this matter soon.

@anarchivist
Copy link
Member

Metadata User Stories are potentially relevant here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants