Q: Regarding the role of Vocbench administrators. Are they somehow related to the roles that one can have into the VRE or not yet? Can a VRE user become a VocBench administrator?
A: No, the administrator account is unique and unrelated to her role in the VRE, i.e. you define an administrator account (using her email) at the setup phase of the VocBench installation. Regular VRE users can be defined as project managers to specific projects and have full control over those projects.
Q: Does it matter if someone use capital letters or not in the definition phase?
A: Yes, it does, as RDF is case-sensitive. It is good practice, however, to not use differences in capitalization for distinguishing entities and properties.
Q: Are spaces and other special characters are allowed?
A: No, the names should follow URL conventions, so spaces, tabs and other similar special characters should be URL-encoded.
Q: If someone want to define property chains can define it programmatically? If someone want to declare relationships between properties, for instance properties chains can define it programmatically?
A: Yes, complex expressions for the domain and range of a property are supported via the usage of class expression interface
Q: If a member willing to contribute to an ontology but does not know the project that have been created, is there any option for him to contact the ontology manager?
A: This is a matter of establishing an access policy for the specific deployment. For example, there is a role that is called RDF geek which essentially is a user that just can see the project and go through what has been defined so what could be established is that each member of a VRE is automatically given an RDF geek role for every project in the VocBench installation visible in the VRE and if he wished to contribute to the project he can contact the project manager.
Q: Why should we use ‘:’ before the names?
A: The terms for entities and properties in the ontology world do not mean anything by themselves, they have to be defined in a namespace so if I wanted to use a standard vocabulary like owl, foaf, etc. I should put this before the ’:’ symbol so this is the name of a class not just Task itself. When the class is defined in the default namespace, you don’t need to write it, just put the ‘:’ symbol before it so this means that this class is the WorkPackage class defined in your package in our name space.
Q: If I had already started ontology somewhere else would I be able to just import it into this tool and then continue working there?
A: Yes, you can do that, and in the webinar, there is an example.
Q: Is it possible to extend the range of properties and to have customized ones?
A: Yes, you have just to import the appropriate vocabulary or ontology.
Q: Is it possible in the future to improve the implementation of the error messages we receive from the system using VocBench?
A: This is a difficult issue to be resolved, as changing the tools per se is difficult and follow the logic of a specialized Computer Science community. A possible solution is to collect common mistakes done by users of the AGINFRA+ communities and provide an FAQ with answers and guidelines to such problems.
Q: The final purpose of the ontology is probably not to import individuals to each of the classes. One of the scenarios of how to use the ontologies is for finding content in text documents so that you can automatically find content in large text documents. Can these ontologies be used for such purposes?
A: The actual goal of the ontology that will be used or imported in the VocBench is to feed the VRE catalogs with terms and metadata that can be used for annotating the resources in the VRE. Of course, relevant metadata can be used to annotate other assets (like tools) in future use cases, under the same mechanism for accessing the terms.
Q: Is there any kind of community commenting features? If someone has a concept that is developed between different partners in a community, is it possible to discuss it inside VocBench?
A: There are no community commenting features in VocBench, as it is meant to be used in conjunction with such tools (e.g. the VRE social features!). Hence, we can use links to VocBench projects or concepts and use them within the VRE social networking area, asking people to work on it together.
Q: Regarding specific concepts within an ontology managed through VocBench, is there any access point to the way the concept of the organization is currently described in VocBench? Is it easy to have one link to directly access the current characterization of the term from a post.
A: The APIs produced by AGINFRA+ will support the retrieval of a concept or a property information. Including its link that will lead to its definition within VocBench.
Q: How can someone create a new ontology, i.e. a new VocBench project?
A: She will need to contact the VocBench administrator to set up the project. Again, a specific policy can be defined for submitting the request for a new project, e.g. via the VRE’s issue tracking environment.
Q: If I have Galaxy in my VRE will I have access only to the algorithms in my VRE? Does this depend on VRE?
A: Yes, it depends on VRE because the DataMiner is also dependent on VRE. So in this specific demo, even if the Galaxy instance is linked to the main AGINFRA+ VRE, I have used on purpose the WP7 food security algorithms as WP7 are the ones that have expressed more interest in Galaxy. Using one VRE or another is just a configuration parameter, and after the demo, every VRE will have its own Galaxy instance running on independent docker containers, so when you access your Galaxy instance you will see the specific VRE algorithms only.
Q: Is there a standard for the definition of the tools in Galaxy?
A: The tools are described in a Galaxy proprietary format, which is in XML, it's quite detailed but is not standardized. The format is described here.
Q: Is it possible to called Galaxy from DataMiner?
A: Galaxy has an API to run workflows so it should be feasible, we still need to clarify how the authentication would work in that case.
AGINFRA+ aims to exploit core e-infrastructures such as EGI.eu, OpenAIRE, EUDAT and D4Science, towards the evolution of the AGINFRA data infrastructure, so as to provide a sustainable channel addressing adjacent but not fully connected user communities around Agriculture and Food.
The selected AGINFRA+ Use Cases will illustrate the benefits of applying the Science as a Service approach to pressing research questions from the corresponding research communities.
subscribe to our newsletter