Relating Concepts Across Schemas in Different Projects

[John McCloud]

Hello there!

I am trying to understand how to link concepts across two schemas using an object property like skos:closeMatch in Vocbench. The layout looks like this:

Project 1:
--Concept Scheme 1.1:
----Concept 1.1.1

Project 2:
--Concept Scheme 2.1:
----Concept 2.1.1

And I would like to assert:
concept1.1.1 - skos:closeMatch - concept2.1.1

But I cannot do this, and I think it's because the schemas live in different projects. The only concepts I can relate to are those that exist within either the same concept scheme or possibly all those concept schemes that are loaded for the same project.

According to the ACL, all the projects have read access, so that shouldn't be a problem (assuming I read it correctly). I thought about importing the namespace from one project into another, but when I go to the Namespace Manager to "Add import from Local Project," there are no projects available (the rendering here is odd; it shows me a black line rather than an empty set of dropdown options, so perhaps there is a bug?)

How do I achieve the assertion above? Must I have all concept schemes I'm looking to link exist within the same project? Is that the only way?

Thank you!

[stel...@uniroma2.it]

Hi John,

 

I’m sorry for your troubles, let’s see where the problem is.

 

let’s start by paying Quine, McCluskey, Karnaugh and even Occam our due respects :-) schemes are not part of the game here neither intra nor extra project, the problem boils down to accessing resources from another project.

 

spoiler: yes you can !

 

Now, let’s see where you get your issue.

 

Side note: just for clarification, you might want to import a project only if you want the resource which is being edited in that project to be really part of yours (even if through an owl:import, so ready-only). Importing projects is just a relatively recent feature very useful in those cases where you have both the importing and the imported dataset being maintained in VB (in two distinct projects, typical case: a dataset and the ontology that models it). In such cases, you have the option of owl:importing the data directly from a project, with the added possibility of periodically (on demand) refreshing the imported data, reflecting changes in the data in that project.

Normally, if a “mention” is enough (i.e. it’s ok to say: c1 skos:closeMatch c2, where c1 is local to your data and c2 is from another project, and you don’t need to import it) you can just “fish” elements from the remote project.

 

That said, there are various ways to do what you need.

 

The big one, if you are doing a large effort on alignment, is to use alignment systems, perform a validation of their results etc..

More here

https://vocbench.uniroma2.it/doc/user/alignment_validation.jsf

https://vocbench.uniroma2.it/doc/user/alignment_systems.jsf

and here:

https://vocbench.uniroma2.it/doc/user/edoal_editing.jsf

 

a very simple one, if you just need to refer to an element from an external project, is to use this feature:

https://vocbench.uniroma2.it/doc/user/data_view.jsf#alignment_to_an_external_resource

 

Note that this facilitates the process for using skos/owl alignment properties, but you can always link resources from other projects through any property:

https://vocbench.uniroma2.it/doc/user/data_view.jsf#operations_available_on_the_resource_view
(see “add value from another project”)

 

And now, to go to the core of the problem you have, we need to understand why you don’t see the other projects. Pls notice that project visibility is the same for all procedures above (so import data from other projects, alignment with external resources, add value from another project).

 

Now, when, from project A you want to see the content of project B (e.g. because you want to link a concept in A to a concept in B), it must be project B that gives (at least) read access to project A.

 

So, question: assuming that you are opening the ACL on the target project (the one where you want to fish for concepts to be used as objects of the relation, doing this operation from the source project) and assuming, to the purpose of this example, that the source project is called “agrovoc-core”, do you see something like the image below with the R on agrovoc-core? (so, your target project is granting R access to agrovoc-core, that is the source project)

 

 

 

I’ve tested it over a couple of recent versions and it works. If you confirm that you did the above and still have issues, I would need the version of VB you are using, and possibly some screenshot with explanations.

 

Kind Regards,

 

Armando

 

 

 

--
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/45647c00-b1a0-4dff-8b3e-c3f9d7cba299n%40googlegroups.com.

[John McCloud]

Armando,

Thank you for your thorough explanation of how to address this issue!

From your review, I determined a simpler reference to elements outside of the current project was best (though I am intrigued by the alignment format and service; Jérôme Euzenat's Ontology Matching is one of my favorite references, and I regard Euzenat's work highly). After looking at the ACLs for the projects, read access was available as in your example so I was unsure why I could not align to these external resources as you pointed out in your description.

Curious, I toyed around in the Project space with which projects were opened or closed. As it turns out, a target project must also be opened along with your source project, otherwise, the source project has no visibility into the target project. That is, both the ACL list must be set up for at least Read rights, and the project must be currently "Open." This is probably by design, but it wasn't something I realized. Once both the source and target projects were opened, I was able to assert the triple: concept1.1.1 - skos:closeMatch - concept2.1.1! Hurray!

Some observations on the results of this and quick follow-up questions:

1. I notice that after asserting the references from Concept1.1.1 to Concept2.1.1 in the external project, there appears to be no additional inference performed on that asserted triple. That is, there is no symmetric inference of skos:closeMatch made on the external project's concept to infer that:  concept2.1.1 - skos:closeMatch - concept1.1.1. I assumed this was because of a read-only permission, but even when I set the permissions to read-write, no symmetric inference occurs. But perhaps this is also by design.
2. From #1, if these Concepts and their Concept Schemes are instead in the same project space, then the symmetric inference occurs as expected.
3. While within Project 1 and executing a SPARQL query to explore the path from Concept 1.1.1 to Concept 2.1.1, one is able to achieve a query result for the asserted triple:  concept1.1.1 - skos:closeMatch - concept2.1.1, but no path into concept2.1.1 is possible while concept2.1.1 resides in a different project space. (For instance, I could not manipulate the SPARQL to get concept2.1.1 - skos:prefLabel - "Concept 2.1.1"^^xsd:string to appear in the query results.) This does work, however, if both Concept Schemes and their Concepts of interest are within the same project.
4. From #3, despite being unable to perform a SPARQL query to arrive at the skos:prefLabel for the Concept2.1.1 in an external project, when viewing the the graph from the source project space (Project 1), it is able resolve and render the external Concept2.1.1's prefLabel, Concept Scheme, etc. So, why isn't this information retrievable when making the SPARQL query? Perhaps it can, and I did something wrong?

Please let me know if I can clarify anything.

Thank you very much!

-John

[stel...@uniroma2.it]

Dear John,

 

thanks for your feedback, all clear from your description and yes, probably this project open/close thing will be review in the future. Closing a project has some historical reasons and some that are still up to date. I will not delve into the details but hope to give a more intuitive solution for the (non-immediate) future.

Replies to your questions/observations here below:

1. I notice that after asserting the references from Concept1.1.1 to Concept2.1.1 in the external project, there appears to be no additional inference performed on that asserted triple. That is, there is no symmetric inference of skos:closeMatch made on the external project's concept to infer that:  concept2.1.1 - skos:closeMatch - concept1.1.1. I assumed this was because of a read-only permission, but even when I set the permissions to read-write, no symmetric inference occurs. But perhaps this is also by design.

 

There are two reasons here:

1. Reasoning is never applied by default. As in any RDF editing system (at least, those supporting OWL reasoning) you must activate it. We have two possibilities in VB: one is reasoning supported by the triple store. This is plugin-specific and can be set on the repository configuration (through VB, which gets the triple-store specific configuration that is modeled in the connector for each triple store). We also have a trivial reasoning sail, which just completes basic patterns such as inverse properties, symmetric ones etc... The difference between the two is that the trivial one does not write in a inference graph but asserts the inferred knowledge.
2. However, in general, we do not allow automatic writing on a different project. When you are in your project, you can only write in it.

 

Indeed, what you suggest is an interesting evolution: that could also be a nice application of the W setting on the ACL, which exists in theory (and for sake of completeness) but, until now, it has never been applied :-)

I would model it not even under any reasoning profile, rather to make it an explicit option whenever the user has either direct writing possibility on the target project OR there is a ACL delegation on the current project from the target one.

 

In the meanwhile, what I can suggest is that you use a locally federated query (available if you are using GDB, and supported with syntax completion in VB) to invert all alignment properties in a project A pointing to concepts of project B (you can filter them through the IRIs of the objects) and assert them in project B.

https://vocbench.uniroma2.it/doc/user/sparql.jsf#query_editing

https://graphdb.ontotext.com/documentation/9.8/free/internal-federation.html

 

 

2. From #1, if these Concepts and their Concept Schemes are instead in the same project space, then the symmetric inference occurs as expected.

 

Ok, so you already know about setting up reasoning on a project :-)

 

3. While within Project 1 and executing a SPARQL query to explore the path from Concept 1.1.1 to Concept 2.1.1, one is able to achieve a query result for the asserted triple:  concept1.1.1 - skos:closeMatch - concept2.1.1, but no path into concept2.1.1 is possible while concept2.1.1 resides in a different project space. (For instance, I could not manipulate the SPARQL to get concept2.1.1 - skos:prefLabel - "Concept 2.1.1"^^xsd:string to appear in the query results.) This does work, however, if both Concept Schemes and their Concepts of interest are within the same project.

 

See previous reply. In general, each project writes on its own repository and that’s for good (I think I explained the whys in some other recent thread) but internal SPARQL federation (in GDB) is really helpful.

 

4. From #3, despite being unable to perform a SPARQL query to arrive at the skos:prefLabel for the Concept2.1.1 in an external project, when viewing the the graph from the source project space (Project 1), it is able resolve and render the external Concept2.1.1's prefLabel, Concept Scheme, etc. So, why isn't this information retrievable when making the SPARQL query? Perhaps it can, and I did something wrong?

 

Rendering and access to external resources is a broader (and more complex) aspect, as it involves also resources on the Web (VB is also a linked data browser). It is dealt with in many ways and we mostly try not to use GD’s internal federation, to avoid solutions that are triple-store specific. In general, if a triple store has a very good feature, we try to generalize it and make it available. However, if it’s not something widespread, that we can assume each triple store has, just with different implementations, we avoid using it for VB’s base features. What you observed is just VB resolving the external labels by querying the other projects (providing that they are accessible, for any reason, by the one the user is viewing, see again permissions, ACL, etc..). Obviously it has a cost as it involves separated queries (one for each project having at least a resource pointed by the resview you are opening), and that’s part of the delicate trade-off in avoiding too many queries connected to a single service.

 

 

Kind Regards,

 

Armando