Uniform (implementation-neutral) syntax to access arbitrary content within a mapping set

[gouttegd]

I am thinking about building a compliance test suite that SSSOM implementations could use to check their coverage of the standard (which slots and features they support or not).

One part of such a test suite would consist of tests in which:

1. we provide a SSSOM input file;
2. we use the tested implementation to retrieve one particular value from the file (e.g. one particular slot from either the set metadata or one of the mapping records);
3. we compare the retrieved value with what we expect.

In order to do that, it would be useful if we had a common syntax, that would be understood by all implementations (it would be part of the spec), to unambiguously refer to an arbitrary piece of content within a SSSOM mapping set.

This syntax should allow to specify 3 elements:

1. the object from which we want to retrieve a value (either the mapping set, or one of the mapping records; if the latter, then it should also allow to specify which mapping record, e.g. the first record in the set, the 7th record in the set, etc.);
2. the type of content we want to retrieve (either a standard slot, a non-standard slot aka an extension slot, or a “special” value);
3. the name of the exact content we want to retrieve:
   1. if we want to retrieve a standard slot, then it should be the name of the slot; in the case of multi-valued slots, it should also indicate which item in the list (the first item, the second item, etc.);
   2. if we want to retrieve an extension slot, then it should be the property associated with the extension slot in the extension definition;
   3. if we want to retrieve a “special“ value, then it should a keyword representing that special value (for now I can think of two: sexpr to retrieve the canonical S-expression representing a mapping record, or hash to retrieve the hash of a mapping record).

Examples

Using some kind of “path-like” syntax:

• set/slot/mapping_set_id: retrieve the value of mapping_set_id slot from the mapping set;
• set/slot/creator_id/1: retrieve the first value in the creator_id slot from the mapping set;
• mapping/5/slot/subject_id: retrieve the subject_id slot from the 5th mapping record;
• mapping/last/extension/https://example.org/fooProperty: retrieve the extension slot associated with the property https://example.org/fooProperty in the last mapping record;
• mapping/1/special/hash: retrieve the SSSOM standard hash of the first mapping record

Alternatively, using some pseudo JsonPath-like¹ syntax:

• set.slot.mapping_set_id
• set.slot.creator_id(1)
• mapping(5).slot.subject_id
• mapping(last).extension(https://example.org/fooProperty)
• mapping(1).special.hash

Thoughts?

---

¹ Why not using exactly JsonPath instead of devising a new syntax? Well, first we cannot assume that all implementations use a JSON representation of the data under the hood – SSSOM-Java doesn’t for example, and AFAIK SSSOM-Py only does it for the set metadata, not the mappings metadata. Second, this would not allow to access non-standard slots or special values.

[matentzn]

it would be useful if we had a common syntax, that would be understood by all implementations (it would be part of the spec), to unambiguously refer to an arbitrary piece of content within a SSSOM mapping set.

I can see that and I can only marvel at your inventive thinking.. Very cool!

Why not using exactly JsonPath instead of devising a new syntax?

That would have been sort of my question too, just to avoid the need of documenting another syntax;

Well, first we cannot assume that all implementations use a JSON representation of the data under the hood – SSSOM-Java doesn’t for example, and AFAIK SSSOM-Py only does it for the set metadata, not the mappings metadata.

I can see that we don't use JSON uniformly as the underlying data structure, so I get that we would not be able to use a JsonPath processor. ... but does that prevent us from using the JsonPath syntax (and only implement our own processor)?

Second, this would not allow to access non-standard slots or special values.

Can you give an example of why it would not allow that?

[gouttegd]

I get that we would not be able to use a JsonPath processor. ... but does that prevent us from using the JsonPath syntax (and only implement our own processor)?

“Only”? Have you looked at the JSONPath spec (RFC 9535)? It’s longer than the entire SSSOM spec!

Implementing a JSONPath processor would be a complete project on its own. I don’t think any SSSOM developers has the bandwidth to do something like that. I know for sure I wouldn’t do that for SSSOM-Java, and as for SSSOM-Py, given that we have not yet been able to implement condensation/propagation even though the feature (1) has been fully specified for more than a year and (2) is much more simple than a JSONPath processor… I can pretty much guarantee it will never happen.

The only way it would be reasonable to use JSONPath would be if developers were able to simply use an existing JSONPath parser/processor, something that, in effect, is not possible for the reason I already gave.

Besides, JSONPath is not only too complex to implement, but I’ll also argue that it is way too complex for what we need – a simple way to access one value from one set. Being able to run arbitrarily complex queries like “give me the predicate of all mappings for which the confidence score is higher than 0.7 or that have been manually curated” ($.set.mappings[?@.confidence > 0.7 || @.mapping_justification != semapv:ManualMappingCuration].predicate_id) may sound nice, but that is way overkill here – and in fact specifying something so complex will only guarantee that no implementation will ever support it.

We (well, I) want a syntax that is simple enough that all implementations can easily support it, because support for that syntax would be a prerequisite for using the compliance test suite.

[gouttegd]

if developers were able to simply use an existing JSONPath parser/processor, something that, in effect, is not possible for the reason I already gave.

The only easy way I can think of to do that would be to do something similar to what ROBOT does to support SPARQL (which converts an ontology from the OWLAPI model to the Jena model, solely so that it can use Jena to run the SPARQL queries): convert the entire set into a JSON structure, solely for the purpose of being able to use a pre-existing JSONPath processor independently of how the implementation normally represents a SSSOM set.

It’s an incredibly ugly approach, and I’d rather withdraw the whole idea than to contemplate encouraging such a hack.

[gouttegd]

Second, this would not allow to access non-standard slots or special values.

Can you give an example of why it would not allow that?

I was starting from the hypothesis that implementations would reuse an existing JSONPath processor (which obviously would not know anything about the ”special” values in SSSOM).

It would of course be possible to access any special values we want if we merely reuse the JSONPAth syntax while asking developers to implement it themselves… assuming developers actually bother to implement such a complex thing.

[matentzn]

“Only”? Have you looked at the JSONPath spec (RFC 9535)? It’s longer than the entire SSSOM spec!

Haha ok. In this case - my only concern is resolved. I think I am onboard with your suggestion, even if it still feels a little like "mit Kanonen auf Spatzen schießen"; The design looks solid anyways!

[gouttegd]

I think I am onboard with your suggestion, even if it still feels a little like "mit Kanonen auf Spatzen schießen";

If you have another idea for how to test that parsers written in completely different languages give you exactly the values that you expect, I am listening.

[matentzn]

If you have another idea for how to test that parsers written in completely different languages give you exactly the values that you expect, I am listening.

No this is how I would probably end up doing it, but I have to say, and you know this very well, that my track record of building solid test suits is.. well to say it politely, "lacking". Or in other words, "criminal". Basically I would usually copy paste every test case manually and change the values for the tests, crying when the schema changes.

So, what you are saying makes the most sense.