Resources (classes, properties, etc.) returned by a search are not related to the containing mod:SemanticArtefact

[manuelfiorelli]

When searching for a resource, the search endpoint seems to just return a collection of resources.
If the @id of these resources is their original URI, it seems to me that there is no way to find the mod:SemanticArtefact they belong to.

[jonquet]

That's a very good point that I missed originally. This is because MOD does not specify anything to link/relate an SA and its content. As you have observed the notion of "content" is not yet formalized within MOD.
@imadbourouche an idea/proposition on how to address this on our side ?we may have a link already ?

[imadbourouche]

Yes in our current implementation we have link already to the related artefact (ontology) in the links part

But we can also add attribute to our classes/concepts ..etc like this one

i made an issue to fix it in our side: agroportal/project-management#716

[jonquet]

Thanks @imadbourouche and @manuelfiorelli note that ontologyId is not in MOD namespace.

[manuelfiorelli]

I see one potential problem, here. Suppose that a resource appears in two semantic artefacts, which indeed, seems to be common in the biomedical realm.

Should we have two resources, each with one ontologyId, or one resource with two ontologyIds. Also, notice that the @id of the resource is the content-resource URI, not a a third-resource representing the result for a cocept and semantic artefact.

[jonquet]

Hello.

Should we have two resources, each with one ontologyId, or one resource with two ontologyIds.

I see this point and it will certainly depend very much on how the SAC deal with term reuses. Are terms reused "fusionned" or "not fusioned" in the back... In OntoPortal, we store content from ontologies in different graphs (not fusionned approach) and detect reuse (by matching URIs) in interfaces. We consider "c1 defined in o1" and "c1 resused in o2" two different terms in our backend with the same original URI (but not the same local identifier (which incorporate the ontologyID indeed).
Consequently, in your example we will return 2 results with one OntologyId
I don't think this is required by MODAPI to take a stake on this. Let's leave each SAC to do what they want based on the way they manage reuses.

notice that the @id of the resource is the content-resource URI, not a a third-resource representing the result for a concept and semantic artefact

Good point to.
As we return RDF and encourage the semantic web I would continue to do this (i.e., have @id by the original URI).. but its true that this id is not really a unique identifier... on our side we have the "self" property to distinguish c1 in o1 and c1 in o2.

On this point again, those questions raises from the fact that MOD is too light wrt the specification of the ontology content (there is not mod classes to repressent the content of mod:SA yet).