-
Notifications
You must be signed in to change notification settings - Fork 3
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
Issues on the WG, what next? #11
Comments
Good points. I've added them as first item on next meeting's agenda. Lets elaborate on ideas/opinions here leading up to the call. |
The big difference between this group and the OBI one that I sit as a curator on is that OBI is discussing terms only for inclusion (or deprecation) in its own domain. There are some WG principles we could discuss and put on paper. Quickly, I can think of:
The Dietary terms spreadsheet has been an interesting case to get rolling with because it was largely request driven, and is a bundle that works together, looks like it fits well in ONS but we'll perhaps reach a final decision on that in next call. The current round of discussion there makes it seem like all the pressure is on ONS to change. I foresee that future term issues may be discussed more piecemeal as they are brought to the WG by members. Possibly this could look alot like OBI and other curation calls where each term request is documented on Issues board, where a "NTR" new term request goes through a cycle of discussion on the call, with definition revision, but with an added twist that the target ontology team has the final say. In theory the target group shouldn't feel pressure to conform to WG recommendations, but I can see how that would be tough - leading the WG to be a defacto cabal! But this may not really be a problem to the extent that future terms would clearly have a home in just one WG member ontology, and would benefit from the host ontology team's guidance that the rest defer to. By harmonizing on definition semantics, the WG may resemble the expert community that is mainly there to ensure smooth interoperability by enabling their needs to be met in each other's work. No cabals! |
One other angle is that the WG benefits from non-ontologist members, and members who sit outside the BFO/OBOFoundry paradigm, as experts who can guide us to ensuring the ontology can echo real-world professional distinctions to accommodate along side any pure ontological treatments, and to take into account other paradigms of thought. |
I would also be happy to know how the work will be done, and how to contribute the best way By the way, should one create a new issue to comment on the whole schema? One general comment/question is : how are the food manufacturing process and the agronomic food production process related to each other? are they both part of a higher-level process model ? and also, I do not really catch the meaning of "planned food-to-food transformation process" nor the difference with food production process (which is an agronomic process) This needs some further explanations but building the big schema is challenging and exciting! |
I'll create a new issues thread for the diagram, and move your questions over there! Thanks! |
That's a good vision of the WG. Let's say that, aiming a a single paragraph description, it's almost like a permanent workshop on ontologies in the nutritional and food domain, in which single ontology developer/representative arrive to collect feedback on their resource from other developers who covered a different facet of food and nutrition and from other peers with different backgroud and involved in the food and nutrition field at different levels. The participants should surely not feel pressure of applying discussed changes, but they should have an open attitude to changes and discussion of their resources. In this light, the WP "wins" if achieve to effectively attract a diversified and large user-base for contribution to all the diversified ontologies.
I think I got the point. Hence, BFO and general compliance with OBOfoundry principles could not be a requirement? |
Yes, very much a permanent workshop! I've added a Principles section to the WG document, so lets add the paragraph / points there. Regarding BFO and OBOfoundry - Asking all members to conform to those principles/paradigms would be too exclusionary in my opinion. But I can say I need to keep FoodOn within those paradigms and I see the benefit of doing so in terms of naming conventions, interoperability, and logic. When I said "methods that go beyond BFO", this may well apply to ontologies like the SOSA sensor ontology that sits outside BFO and RO (but may be mappable). But also, practices which are BFO / IAO / OBI compatible but aren't detailed in BFO, like process modelling with inputs and outputs (which are likely generic enough to map to other paradigms too, but I try to avoid a mapping quagmire by adhering to OBOFoundry in the first place.) |
Closing this as issue resolution is a result of dialogue between individual ontology curators involved. |
As some discussion on term addition and/or adjustment has already been made, I was wondering how should the process for eventually making those changes effective be like.
Below some discussion points that come to mind:
As various ontology are already involved and growing in numbers, should the WG establish a specific process to turn issues into "production" changes?
When should the WG consider the discussion on a term completed? In other words, when is consensus reached in the presence of discordant comments? Some sort of voting/poll? Obviously, further discussion and edit are always possible with issues, but when a discussion arise, I think that it should be declared completed at some point.
Should the WG consider be considered, at a certain point, as some sort of consortium having certain degree of decision power over the single ontologies? The general schema presented by Damion on the lat virtual meeting (June 24, 2020) but I think it requires an extensive work on othogonality, even if the BFO common root is handy.
Those are just some consideration, not necessarily all important. However, point 1 and point 2 appear quite relevant at the moment, especially for ONS that was the subject of most of the issues, and I would find useful to discuss operational standards before committing to apply modifications.
The text was updated successfully, but these errors were encountered: