Representing data model elements and their values in SSSOM

[matentzn]

Case:

we want to map literal values in a set of permissible values in a data model (say "M" in gcs.maritalstatus) to some ontology term NCIT:Married. Now there might not be anything like an id for the permissible values in the data model. One solution could be to do something like _:b in the subject or object_id column to indicate this is a blank node, meaning that the label should be used for the mapping, but maybe we need something more general to allow for mapping arbitrary literals, as @wdduncan suggested in another thread as well..

From @hsolbrig:

We DO need a way to represent a specific string that appears in a given data element but I see this as a case where we are imposing the constraints of OUR data model (RDF)  on a pretty straight-forward idea – string “M” in the marital status data element in model M means “Married” as defined by ontology … .  I wonder whether this may be a case where we are overburdening the notion of an “ontology map”.   Note that using the actual map if it is in RDF is going to require the same amount of work whether the source nodes are represented as Uri’s or BNodes.

[wdduncan]

I think being able to do this would be awesome!
Suppose we have a table with two three columns:

• person_id
• marital_status
• gender
  In the marital_status column the value "m" means married, and in the gender column "m" means male. We also have an ontology "ont" that has classes to represent instances of people, marriage, genders.

Focusing just the columns we can do this (the is what we do for the NMDC mappings at least).

table.vocab:person_id skos:exactMatch ont:person
table.vocab:marital_status skos:exactMatch ont:marriage_status
table.vocab:gender skos:exactMatch ont:gender

Mapping specific values is trickier. I think we will need new predicates. E.g.:

table.vocab:marital_status sssom.vocab:value _:v1
_:v1 skosxl:literalForm "m"
_:v1 skos:exactMatch ont:married
table.vocab:gender sssom.vocab:value _:v2
_:v2 skosxl:literalForm "m"
_:v2 skos:exactMatch ont:male

I used blank nodes in this example, but I see no reason why they have to be blank.

Perhaps we can also make use of the match_string field. E.g.:

subject_id	predicate_id	object_id	match_string
table.vocab:marital_status	skos:exactMatch	ont:married	"m"
table.vocab:gender	skos:exactMatch	ont:male	"m"
table.vocab:person_id	skos:exactMatch	ont:person

The match_string field is blank for for the person_id mapping, so we could apply to all. values.

[wdduncan]

@matentzn any more thoughts on this? Add @cmungall to the converstation.

[cmungall]

Good comments, will respond in more detail later

one comment: match_string isn't really intended for this. It's for provenance for a lexical match

[cmungall]

Related ticket on how to map strings/enums to ontology terms in blml: https://github.com/biolink/biolinkml/issues/170

[ddooley]

https://schema.org/codeValue would be appropriate for indicating a string match?

[wdduncan]

@ddooley I suppose it depends what is meant by 'code'. Does it have to relate to a code system? E.g., ICD 10 code 'F33.1' represents 'Major depressive disorder, recurrent, moderate'. For many enums this may make sense, even though the "coding system" may only apply to a particular study. E.g., In my study, I choose to use "99" to represent unknown values.

But we may want to represent literal names of things, e.g., the strings 'morning star' and 'evening star' denote the planet Venus.

[ddooley]

Looks like the schema intangible https://schema.org/DefinedTerm would be a more general term (like an OWL class) spelled out in full via "name" property, and with "termCode" as a sub-property for an associated code. Thx for drawing my attention to that.

[wdduncan]

Sure, I suppose DefinedTerm works. Although, you still need to link the literal to the IRI that specifies its meaning.

There are some standard properties for linking objects to literals: rdf:value, owl:hasValue. The range can be either an IRI or a literal. E.g:

table.vocab:marital_status owl:hasValue  _:v1 .
_:v1 owl:hasValue "m" .
_:v1 skoslx:exactMatch ont:married .

table.vocab:marital_status owl:hasValue_:v2 .
_:v2 owl:hasValue "s" .
_:v2 skos:exactMatch ont:single .

In SKOS, skosxl:literalForm is an option too. If we adhere to SKOS standards, the modeling would be like this:

table.vocab:marital_status skosxl:prefLabel _:v1 .
_:v1 a skosxl:Label .
_:v1 skoslx:literalForm "m" .
_:v1 skos:exactMatch ont:married .

table.vocab:marital_status skosxl:prefLabel _:v2 .
_:v2 a skosxl:Label .
_:v2 skosxl:literalForm "s" .
_:v2 skos:exactMatch ont:single .

Although this is a bit more verbose, it at least stays within the SKOS ecosystem. The statements _:v1 a skosxl:Label and _:v2 a skosxl:Label can perhaps be excluded.

I am a little wary of schema.org. They don't seem to be focused on ontology, but mostly focused on stings.
Using DefinedTerm, we would still need to link the literal to the IRI that specifies its meaning. I supposed the modeling could look something like:

table.vocab:marital_status owl:hasValue  _:v1 .
_:v1 schema:DefinedTerm "m" .
_:v1 skos:exactMatch ont:married .

table.vocab:marital_status owl:hasValue_:v2 .
_:v2 schema:DefinedTerm "s" .
_:v2 skos:exactMatch ont:single .

Is this any better or worse? You have to make use of owl:hasValue, schema:DefinedTerm, and skos:exactMatch, which may bother some.

[wdduncan]

has anymore consideration been given to this?

[wdduncan]

Did we reach a consensus on this? It is quite important. In the NMDC we are using enums to control the meanings of values, but using an SSSOM file to provide mappings/means for GOLD column names. It would be great if we could provide meanings/mappings for individual values in a SSSOM file.

[matentzn]

I think its pretty much clear that we allow complex expressions instead of subject_id, object_id. What I am not clear yet is how these should be represented - that's why I stopped thinking because your use case differs a lot from mine. I definitely do not want some weird concept like "named blank nodes" - In this case better mint an ID. What I prefer is patterns and complex expressions associated with a subject_id field. I prefer to organise a meeting for this and discuss it - this ticket has become to confusing for me. What do you thinking? Maybe we can just meet between the two of us and hash out a good solution?