Mappings to SKOS?

[osma]

I realize that the 3-level structure of MeSH is difficult to represent using SKOS (I have read the AMIA paper about desiredata for MeSH RDF). But I think it would still be useful to provide mappings from the meshv classes and properties to SKOS, to enable some degree of compatibility between the MeSH RDF version and SKOS-aware tools.

In particular, I think these subproperty axioms for labels should be completely valid, as SKOS labels may be used for any type of resources, not just SKOS concepts:

meshv:prefLabel rdfs:subPropertyOf skos:prefLabel .
meshv:altLabel rdfs:subPropertyOf skos:altLabel .

Likewise, I think many of the MeSH documentation properties are very similar to SKOS and could perhaps be mapped, e.g.

meshv:historyNote rdfs:subPropertyOf skos:historyNote .

I am less sure about classes. It might be possible to assert e.g.

meshv:Descriptor rdfs:subClassOf skos:Concept .

but I'm not completely sure about the implications here.

Even less likely is being able to assert mappings for hierarchical relations, e.g.

meshv:broader rdfs:subPropertyOf skos:broader .

because of the peculiarities in the MeSH hierarchy. But that should be taken as a challenge ;)

I think you shouldn't dismiss SKOS out of hand, even if it may not match the requirements of MeSH completely.

On a related note, you seem to have adopted a style of data description where you coin new classes and properties for everything, even for common things which can be already found in e.g. Dublin Core or SKOS. The alternative would be to try to reuse existing vocabularies as much as possible. I hope you have considered that option as well, because it might make interoperability simpler for people, agents and tools reusing your data.

[bushmanb]

Comments received from Stanford (NCBO): It appears that this model is using terms that look exactly like SKOS terms but are not SKOS terms and are instead defined (redefined?) in the mesh namespace. Examples are things like broader and narrower. This seems unfortunate. There is already a large community of users who are familiar with SKOS so using these terms but not referencing SKOS appears a bad choice. If you have decided for some reason to not use SKOS then you should probably not use the SKOS names for everything and invent your own. Instead though it would be preferable to just adopt SKOS where it has the functionality you need.

[flamingofugang]

I believe the reason that we changed from skos to meshv namespace is that skos cannot fully capture the relations between different types of nodes, For instance, the broader relations can happen to any of three: meshv:descriptors, meshv:concepts, meshv:treeNumber. So the domain and range are different. In addition, one may be transitive and another may be reflexive.
To refine the model, we can try to connect to and extend (or specialize) skos, like what is suggested here:
http://www.w3.org/TR/skos-primer/#secskosspecialization
So we may have:
meshv:broaderDescriptor
meshv:broaderConcept
meshv:broaderTreeNumber
and the first two are sub-properties of skos:broader, and the third is sub-property of skos:broaderTransitive, since it is a transitive property.
Any comment?

[obodenreider]

MeSH cannot be properly represented in SKOS. Period.
We would need to be extremely careful if we wanted SKOS predicates. For example, are tree numbers SKOS concepts? That would be a stretch.

Olivier

On Dec 2, 2014, at 12:41, Gang Fu <[email protected]mailto:[email protected]> wrote:

I believe the reason that we changed from skos to meshv namespace is that skos cannot fully capture the relations between different types of nodes, For instance, the broader relations can happen to any of three: meshv:descriptors, meshv:concepts, meshv:treeNumber. So the domain and range are different. In addition, one may be transitive and another may be reflexive.
To refine the model, we can try to connect to and extend (or specialize) skos, like what is suggested here:
http://www.w3.org/TR/skos-primer/#secskosspecialization
So we may have:
meshv:broaderDescriptor
meshv:broaderConcept
meshv:broaderTreeNumber
and the first two are sub-properties of skos:broader, and the third is sub-property of skos:broaderTransitive, since it is a transitive property.
Any comment?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-65271400.

[osma]

So we may have:
meshv:broaderDescriptor
meshv:broaderConcept
meshv:broaderTreeNumber
and the first two are sub-properties of skos:broader, and the third is sub-property of
skos:broaderTransitive, since it is a transitive property.

Almost but not quite. You shouldn't map to skos:broaderTransitive, because it is actually a weaker assertion than skos:broader (according to SKOS, skos:broader is a subproperty of skos:broaderTransitive). This is a fairly common mistake, largely due to the unfortunate naming of those predicates.

[obodenreider]

What about broaderQualifier?

Olivier

On Dec 2, 2014, at 22:21, Osma Suominen <[email protected]mailto:[email protected]> wrote:

So we may have:
meshv:broaderDescriptor
meshv:broaderConcept
meshv:broaderTreeNumber
and the first two are sub-properties of skos:broader, and the third is sub-property of
skos:broaderTransitive, since it is a transitive property.

Almost but not quite. You shouldn't map to skos:broaderTransitive, because it is actually a weaker assertion than skos:broader (according to SKOS, skos:broader is a subproperty of skos:broaderTransitive). This is a fairly common mistake, largely due to the unfortunate naming of those predicates.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/12#issuecomment-65361163.

[micheldumontier]

This conversation is still abstract. Can you illustrate with a concrete example as to why SKOS predicates is insufficient and requires this specialization?

[stain]

+1 to add explicit SKOS mapping to the vocabulary. I'm OK with keeping the specialized properties.

Pretty much anything can be a skos:Concept as it does not come with any scary implications, but mapping to skos:broader and skos:narrower should take the implied SKOS transitivity in consideration. Note that the transitivity on SKOS relations would not imply transitivity on the mesh properties unless they also claim to be transitive.

[VladimirAlexiev]

Have you guys considered https://code.google.com/p/hive-mrc/wiki/MeshToSKOS ?

[akuckartz]

Any news regarding MeSH expressed using SKOS ?

[danizen]

@akuckartz, we've considered adding relationships such as owl:sameAs to equate meshv:prefLabel to skos:prefLabel, and things such as this. The limitation with this approach is that many backends support RDFS reasoning, but not OWL reasoning levels. This includes our own backend, and so skos could not effectively be used for search within our SPARQL backend or query editor.

So, I put the question to you and the rest of the community - do you primarily interact with our data, or our SPARQL endpoint?

If our downloads and pages were still directly expressed using properties such as meshv:prefLabel, but these properties were equated to skos:prefLabel in the ontology, would this be of sufficient use to you?

[danizen]

@osma, @akuckartz et. al, we will take this up in our internal working group, but we are moving away from Github issues. I'm closing this now, but rest assured we have an internal report to track it.

[akuckartz]

So this project is becoming less transparent. Sad.

[danizen]

@akuckartz, hopefully we are perhaps also more active ;)

[VladimirAlexiev]

http://thesauri.cs.vu.nl/eswc06/ has MeSH as SKOS. The date is 9 feb 2007

[VladimirAlexiev]

@stain skos:broader and skos:narrower are not transitive

[danizen]

@akuckartz , we have reconsidered an end to github issues, and are discussing it. I'll re-open this pending that discussion.