Showvoc datasets with instances + ontology model
Thomas Francart
- In VocBench, data is separated in multiple projects:
- one project contains the OWL ontology definition with classes and properties
- other OWL projects contains instances of the classes, separated in different projects (e.g. organizations in one project, countries in another, and persons in a third one). They owl:import the ontology project, so that we see the class tree.
- other SKOS projects contain SKOS controlled vocabularies
- In ShowVoc we need to disseminate all these datasets:
- for SKOS projects we create SKOS datasets and it works fine
- for OWL projects containing instances, if we want the class tree to be displayed in ShowVoc, and since Showvoc cannot owl:import the ontology dataset as in VocBench, we also load the ontology model data file along with the instances. Otherwise we don't see any class tree.
- Hence the need to customise the root class, as indicated in previous thread, otherwise the tree is too messy for end users.
--
linked data | domain ontologies | knowledge graphs
blog : blog.sparna.fr, site : sparna.fr, linkedin : fr.linkedin.com/in/thomasfrancart
tel : +33 (0)6.71.11.25.97
stel...@uniroma2.it
Dear Thomas,
by first, let me take the occasion to apologize: I see you have a few unreplied messages in list. I assure you, definitely we have no beef with you :-P The rationale is simple: you are a very advanced user and a good part of your questions require some time to recreate the issue, test, and also to come up with some solution. Add that this is a very dense (if not chaotic) year and the..queue is done :-D They are still on our TODO list and we will try to sort them out in the next weeks!
About this: you highlight indeed a gap in ShowVoc: lack of an import management. The rationale was that SV is not for editing (originally the import management was mainly for “adding/removing” imports of ontologies) but, especially with the latest additions, import management is more than that: if we removed the part where we can add an import (thus altering the original dataset with an owl:import triple), then we would be left with a perfect management tool for ShowVoc, making the user able to fix all imports that do not resolve on the web (sadly, many ontologies on the Web do not resolve…) , so not altering the structure of imported ontologies, just allowing users to load them externally (in one of the many ways we enable it: local file, alternative URL, dataset catalog…) if they do not resolve automatically. Without this, we would have no explicit mean to do so and the only workaround would be to export from VB not only the main data, but also the imported ontologies and then load all the stuff in SV.
And here we come to a needed patch that was already on our roadmap for the next delivery: even that workaround…doesn’t work around! When we load something through the load service, it is always flattened in a single graph. The historical rationale was that we did not have (at the time, now it’s possible) a way to edit other graphs but, besides the limitation, we wanted to have in any case all editing data in the same graph. We will change this because respecting the provenance should always be an option; decisions on the final details are being taken in these days (use an option, which one is the default, etc..) but you will be able to import a file with multiple graphs, keeping the provenance as-is, without flattening data in a single graph.
As for really avoiding duplication, having separated versions of imported ontologies is intended in any case to have a copy for each project, as each project has its own repository (spoiler, it will have more repos in the future!) and, in any case, it’s better to compartmentalize even imported data for each project. In VB, some time ago we added the possibility to create a dependency from a project to one another (e.g. dataset in project A owl:import an ontology in project B) to simplify maintenance (from project A you can simply ask to update the imported ontology to its evolved version in project B) in those cases where many datasets are evolving together with the model they depend on, but still you need a copy in your own project and it’s for good. However, I think the aspect you were mostly interested in was the possibility to separate (with graphs) the data from the model and the redundancy you wanted to avoid is simply dictated by the merged presence of the same model in different datasets.
So, this improvement should come with the next release, around end of October. For now, you have in any case your master data solidly separated and organized in VB so, there is no disruption that would be caused during this wait, simply you will have, for ontologies that cannot be resolved automatically on the web (SV does that automatically after a load) since you have no fix option, it’s better if you export them ready from VB and yes, they will be merged with the data in the current setting. A full owl:import management panel (stripped of the editing part related to adding/deleting imports) will come, maybe next year.
Cheers,
Armando
P.S. If you want something more in the meanwhile, I could suggest two hacks:
1. this is trivial, so you surely have already thought about it: do it in the triple store. I call it an hack because we always recommend to have everything done through VB/SV due to potential connected actions performed by the systems but if you know what you are doing, it’s an option
2. install a VB client bound to the same ST server and perform the fixes for broken owl:imports through it.
--
You received this message because you are subscribed to the Google Groups "vocbench-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vocbench-use...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/vocbench-user/CAPugn7Wmr0k4oZ-8KjaM6sAcPiTnOoOjjfy4VKG_5b%2B5-VdHew%40mail.gmail.com.