Cory Casanave it would be great to have at least two examples of use (use cases) of FIBO Ratings ontology. One for ratings of legal entities and the other one for the ratings of the financial instruments.
Display on screen or send to downstream system as appropriate
Use Case for Financial Instrument the same except use Financial Instrument instead of Legal Entity
Robert – what more could you ask for? Also the above is obviously a process, something we didn't want to introduce into FIBO since that's the realm of the analyst developing an application. Also the above would apply to practically everything in FIBO – just change the object you're looking for.
John Gemski answering your question: "what more could you ask for". I'd like to have short documentation (that we call "use case") that will step by step walk me, for instance, through your use case (i.e. the one described above by you). In the end, I'd like to see FIBO triples describing examples of "real" ratings. But even before that, I'd like to learn why we need FIBO Ratings Ontology. What is the FCT's motivation for creating it? Is it to be used for integrating ratings data coming from different sources or something else?
On the one hand, I do agree with you that your use case constitutes a process that we do not want to introduce into FIBO. But... on the other hand, a good ontology for Ratings should describe/determine the models we believe are adequate for modelling the ratings. So, the ontology in question should contain classes and properties + restrictions that are necessary to build such models. I opened the Ratings.rdf file in Protege, the one that Cory Casanave sent us before the last FRO meeting, and it was not really clear to me how I should start using it. I'm not saying that it is something wrong with the ontology. I'm saying that without documentation and examples it is not easy to follow... For instance, following your point 1., I tried to find Legal Entity, but there was no such class in Ratings... Of course, I do understand that Ratings ontology is not to contain everything that can be rated. But still, a good use case for ratings of legal entities should say sth about FIBO BE...
And finally a more general comment. My experience with developing ontologies is that modelling real data gives us many insights and often contributes to many changes in the ontology... many ontological choices are being tested. FIBO is not an upper ontology. FIBO is partly a middle-level ontology (FND part) and partly a set of domain ontologies. And as such cannot be seriously build without use cases.
After reading what you wrote I think we agree in principle but not in how to achieve the goal. What I think we need with each diagram is an explanation of the contents of the diagram, plus as you said, a few examples. As an example, adding upon what you wrote above, it would be nice to say that this Rating diagram is a generic model for how ratings are stored and applied to anything that is rated and "thing" in the diagram represents anything that can be rated including Business Entities, Financial Instruments, Accounts, Customers and Geographic Units.
(To answer your specific question as-to where does this go I would say Foundations so it applies to ratings in so many other domains.)
But that's different from Use Cases which typically describe processing steps.
I looked at the OMG documentation which we produced for the domains that are in production – specifically the one on Business Entities. I believe that is close to what both of us would consider necessary documentation for a given diagram. It at least includes the definition of each class so a reader has some idea of what the diagram is describing. I suggest we drop the use of Use Cases and instead work on incorporating diagram explanations that include:
1. A reason for the diagram, i.e., what is the diagram representing and why is this important
2. The definition of each class represented. Yes the definition is available through a hyperlink if you're using a modeling tool but not available in a physical document
3. A list of the attributes within each class and their definitions
John, in fact, I'm more than happy reading your words. There are just a few points I'd like to comment on.
You are talking about "diagram explanation". I would rather say that we should explain/describe an ontology, a part of FIBO, we are dealing with (in our case it is FIBO Ratings Ontology). The ontology can be obviously explained by diagrams, but not the diagrams as such are here the main subjects of explanation.
My "documentation and use cases mantra" has never had any (hidden) intention to kill the generic/abstract nature of FIBO. Every time I had a chance to explain my intentions, I was making clear that each module/domain of FIBO is to be:
documented, i.e. explained/described, by diagrams, the lists of classes and properties with definitions, examples, mind maps, etc. - so, it is exactly what you are saying
tested by at least one use case if it is possible and makes sense.
So, let me stress this once again, having use cases for a module of FIBO we do not restrict the scope of the module to the use cases we have. We just provide an application / an example of usage of the module. Many potential FIBO users really need that (even if some of them say they do not).
5 Comments
Robert Trypuz
Cory Casanave it would be great to have at least two examples of use (use cases) of FIBO Ratings ontology. One for ratings of legal entities and the other one for the ratings of the financial instruments.
Some data: https://public.opendatasoft.com/explore/dataset/ratings-history/table/?sort=par_value
John Gemski
Use Case for Legal Entity:
Use Case for Financial Instrument the same except use Financial Instrument instead of Legal Entity
Robert – what more could you ask for? Also the above is obviously a process, something we didn't want to introduce into FIBO since that's the realm of the analyst developing an application. Also the above would apply to practically everything in FIBO – just change the object you're looking for.
Robert Trypuz
John Gemski answering your question: "what more could you ask for". I'd like to have short documentation (that we call "use case") that will step by step walk me, for instance, through your use case (i.e. the one described above by you). In the end, I'd like to see FIBO triples describing examples of "real" ratings. But even before that, I'd like to learn why we need FIBO Ratings Ontology. What is the FCT's motivation for creating it? Is it to be used for integrating ratings data coming from different sources or something else?
On the one hand, I do agree with you that your use case constitutes a process that we do not want to introduce into FIBO. But... on the other hand, a good ontology for Ratings should describe/determine the models we believe are adequate for modelling the ratings. So, the ontology in question should contain classes and properties + restrictions that are necessary to build such models. I opened the Ratings.rdf file in Protege, the one that Cory Casanave sent us before the last FRO meeting, and it was not really clear to me how I should start using it. I'm not saying that it is something wrong with the ontology. I'm saying that without documentation and examples it is not easy to follow... For instance, following your point 1., I tried to find Legal Entity, but there was no such class in Ratings... Of course, I do understand that Ratings ontology is not to contain everything that can be rated. But still, a good use case for ratings of legal entities should say sth about FIBO BE...
And finally a more general comment. My experience with developing ontologies is that modelling real data gives us many insights and often contributes to many changes in the ontology... many ontological choices are being tested. FIBO is not an upper ontology. FIBO is partly a middle-level ontology (FND part) and partly a set of domain ontologies. And as such cannot be seriously build without use cases.
John Gemski
After reading what you wrote I think we agree in principle but not in how to achieve the goal. What I think we need with each diagram is an explanation of the contents of the diagram, plus as you said, a few examples. As an example, adding upon what you wrote above, it would be nice to say that this Rating diagram is a generic model for how ratings are stored and applied to anything that is rated and "thing" in the diagram represents anything that can be rated including Business Entities, Financial Instruments, Accounts, Customers and Geographic Units.
(To answer your specific question as-to where does this go I would say Foundations so it applies to ratings in so many other domains.)
But that's different from Use Cases which typically describe processing steps.
I looked at the OMG documentation which we produced for the domains that are in production – specifically the one on Business Entities. I believe that is close to what both of us would consider necessary documentation for a given diagram. It at least includes the definition of each class so a reader has some idea of what the diagram is describing. I suggest we drop the use of Use Cases and instead work on incorporating diagram explanations that include:
1. A reason for the diagram, i.e., what is the diagram representing and why is this important
2. The definition of each class represented. Yes the definition is available through a hyperlink if you're using a modeling tool but not available in a physical document
3. A list of the attributes within each class and their definitions
4. Examples at least of each class
What do you think?
Robert Trypuz
John, in fact, I'm more than happy reading your words. There are just a few points I'd like to comment on.
You are talking about "diagram explanation". I would rather say that we should explain/describe an ontology, a part of FIBO, we are dealing with (in our case it is FIBO Ratings Ontology). The ontology can be obviously explained by diagrams, but not the diagrams as such are here the main subjects of explanation.
My "documentation and use cases mantra" has never had any (hidden) intention to kill the generic/abstract nature of FIBO. Every time I had a chance to explain my intentions, I was making clear that each module/domain of FIBO is to be:
So, let me stress this once again, having use cases for a module of FIBO we do not restrict the scope of the module to the use cases we have. We just provide an application / an example of usage of the module. Many potential FIBO users really need that (even if some of them say they do not).