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

Typo in rdfs:comment for classes GainOfDisposition and GainOfFunction #163

Closed
swartik opened this issue Feb 3, 2023 · 3 comments · Fixed by #275
Closed

Typo in rdfs:comment for classes GainOfDisposition and GainOfFunction #163

swartik opened this issue Feb 3, 2023 · 3 comments · Fixed by #275
Assignees

Comments

@swartik
Copy link

swartik commented Feb 3, 2023

In the bfo2020 branch, the rdfs:comment annotations for classes GainOfDisposition and GainOfFunction reference object property occurs_on. The property in BFO 2020 is BFO_0000199, with label "occupies temporal region".

@mark-jensen
Copy link
Contributor

@swartik Thanks! Will be fixed asap.

Curious, are you using BFO2020 and the all/some properties? If so, how are they working out for you? Any problems with translating btw them and RO/ERO?

@swartik
Copy link
Author

swartik commented Feb 6, 2023

@mark-jensen Yes, we are using BFO2020 and its properties. Fortunately for us there was no legacy work to migrate: we based all our work on BFO2020. So we haven't had any translation problems. As I noted in #156, I was surprised to discover that some RO properties had no analogy in BFO2020, but their lack only resulted in using higher-level properties: using bearer of rather than has role. I imagine we will start creating domain ontology-specific properties that reflect the roles we model. So far this has not been important.

In our rush to deliver a product, we are using "some" properties rather than "all" properties unless we are very, very certain a relationship will always hold. We are still prototyping, and are sending graph patterns to our developer, who figures out how to turn data into those patterns. As we work through examples, we may discover a need for an "all" property. At this stage, switching properties won't be a problem: we aren't accumulating data in triple stores yet. And we have not found a need for rigid classes, per @neilotte's comment.

Really, the main problem using the new properties is their longer labels. The diagrams I draw for documentation are larger than in the past. Good thing we're not restricted to 8 1/2 x 11 paper any more.

@mark-jensen mark-jensen self-assigned this Feb 24, 2023
@cameronmore cameronmore linked a pull request Jun 14, 2024 that will close this issue
@neilotte
Copy link
Contributor

neilotte commented Aug 2, 2024

This change has been merged into development. Closing issue.

@neilotte neilotte closed this as completed Aug 2, 2024
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

Successfully merging a pull request may close this issue.

3 participants