Yangfan He: A Self Introduction

Printer-friendly version

Slides

A Self Introduction of Yangfan He [Download]

Discussion

Does automated mapping, using what algorithm?
Yangfan:
Many algorithms for ontology mapping do not suppose that the two ontologies for comparison have any inherent relationship. According to these algorithms, two concepts from the two ontologies can be mapped to each other if and only if the concept names are similar or the surrounding concepts (such as ancestors or siblings or offsprings ) bear some similarity.
In MFI-3, whether the ontology uses some concepts from the other ontologies are explicitly stated. With MFI-3 registration info, we can tell whether two concepts are equal to each other by the “sameAs” relationship, which suggests the reusing of the content from another ontology. So two concepts can be mapped to each other if and only if they can be mapped to the same concept from the third ontology. That’s the basic idea for ontology mapping enabled by MFI-3.

Question about the difference between role goals and personal goals
Yangfan:
Personal goal is mainly used to describe uers’s preference on role goals. Take travelers as an example, “Get a travel plan” is a role goal. Different travelers may have different preferences. Some may ask for a plan which can take him to the destination within the shortest time, some others may ask for a plan which costs least. “Within the shortest time” and “With least cost” are person goals in this example.

  • Eric
    • Interested in software component ontology as it relates to S2S Framework
    • S2S focuses on reusable user interface components
    • wondering what kinds of communication/interaction enabled between users and engineers

Yangfan:
We communicated with some domain experts (invited by KM company) as requested. With their help, we built some domain ontologies.
For requirement engineers, they previously took Taxonomy or Thesaurus in requirement engineering stage. By comparison, OWL based ontologies have a stronger expressive power and provide a better description of the relationship of the concepts .When the users find engineers cannot understand a point well, they can choose to interpret it in the terms engineers have a better understanding. Ontologies facilitate the face to face communication in the requirement elicitation stage.
But it will be more difficult for eScience project, because users will face the web, not a human being. As Patrick once mentioned, it is highly desirable if we can select an appropriate level of abstraction (using more abstract/more concrete terms) to deliver the information. But it is really hard to predict whether a level is appropriate or not. Can we provide a more flexible way to select/adjust the level, just as we did in face2face communication?

  • Patrick
    • Interested in the software component ontology as it relates to provenance
    • The software that was used to process data, constrain, translate, subset, aggregate, etc...

Yangfan:
Ideally, when we doubt the correctness of the data, we can rerun some corresponding systems under the guidance from provenance information.
The software component ontology we built is mainly for the classification and registration of software components. I am not sure whether it can serve the provenance purpose well.
If possible, I want to know more about your definition of the provenance problem in eScience project.

More Q&A about the software component ontology

Q: What did we do in the collaboration with KM Company?
A:
Our efforts were devoted to:
1) build some software components according to their experience in building CAD systems for users in different domains.(They did not utilize software component technology before)
2) Set up the software component repository.
3) Build some OWL based domain ontologies as requested. KM Company used those ontologies to facilitate the communication with domain users.

Q: What benefits did we get to use OWL?
A: Since we use concepts from domain ontology to annotate the attributes of software components. The inference available from the OWL based domain ontologies brings us more insight to the inherent relationship between the software components.

Q: How to describe the function of software component?
A: The class "Functional Attribute” and its subclasses, like input and output, were defined to describe the functions of software components.
From today's view, OWL-S will be a better choice.

Q: Why some class has only one subclass?
A: This figure just showed the main concepts in the Software Component Ontology. Some cocepts are omitted for brevity's sake.

Q: Why did we define the class "SCAttribute"?
A: Without this class, the software component ontology will be a graph centering "SComponent", thus forming a star like structure. Such a structure is not good for navigation.
By comparison, SCAttribute and the other attribute related abstract class constitue a classification of the software component attributes. With these attributes, we can present components to software engineers from different perspectives.