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

Rich Text Descriptions #504

Open
JMante1 opened this issue Nov 21, 2022 · 4 comments
Open

Rich Text Descriptions #504

JMante1 opened this issue Nov 21, 2022 · 4 comments

Comments

@JMante1
Copy link
Contributor

JMante1 commented Nov 21, 2022

Not sure if this should go here or in the best practices section. I am working on grounding terms in text descriptions. To accommodate this we would like to have a rich description field that supports markdown formatting. It would match the original description field (for tools that cannot handle rich text) but provide an alternative formatting with more information.

@cjmyers
Copy link
Contributor

cjmyers commented Nov 26, 2022

If the idea is to add a new predicate in the sbol namespace for this, then it belongs here. If there is a predicate in another namespace that can be used, then it should be a best practice instead.

@jakebeal
Copy link
Contributor

I don't see the desirability of having an alternate description field. A major part of the point of standards like MarkDown and RST is that the material is interpretable even when interpreted as raw text. Having two copies of a description is begging for the description to become forked.

I could, however, see value in having an optional field indicating the preferred markup interpretation of the description. That would be similar to the format field for Attachment. The only sticking point is that EDAM would need to be extended to include Markdown and similar (which it currently doesn't have).

@JMante1
Copy link
Contributor Author

JMante1 commented Dec 6, 2022

I see the point of not having two descriptions. I think something that indicates if it is plain text, markdown, or similar would be a good idea though. If the tag is not present it can be assumed it is plain text. Are there other ontologies we could use in the meantime?

@jakebeal
Copy link
Contributor

jakebeal commented Dec 6, 2022

I'd suggest requesting a term from EDAM and using a local term as a placeholder.

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

No branches or pull requests

4 participants