Semantic significance of "dot notation"

[baskaufs]

I was reading though the 3. Latimer Schemes documentation to try to understand how they worked. I was wondering if you could clarify a bit about the serialization used in the examples. Because of the @context and @type statements I was thinking that it was JSON-LD, but it doesn't really come out right in the JSON-LD playground (most of the properties are missing because they aren't included in any context). So I'm thinking that the examples are sort of "JSON-LD-like" rather than intended to actually be JSON-LD.

I'm also wondering about the dot notation. It doesn't really fit in with any RDF serialization, so I'm assuming that it's just a convention that is local to Latimer Core. Am I understanding that right?

[mswoodburn]

Hi Steve! Good point about the examples - they've ended up being JSON with some nods to JSON-LD rather than being valid JSON-LD, more by oversight rather than by design. I'll create an issue for this and update them to code which validates appropriately in the JSON-LD playground.

On the dot notation in SchemeTerm examples: no, it doesn't follow any particular formal convention, rather it's a local method of trying to be explicit about the relevant chain of linked classes and child properties. The main reason for this is that LtC has those generic classes (e.g. Identifier) that may be reused in the context of various other classes (Person, OrganisationalUnit, Taxon etc). In defining the terms that we want to include in a particular scheme, we might for example want to state that identifiers for OrganisationalUnits are mandatory ("termName": "OrganisationalUnit.Identifier", "isMandatoryTerm": true) but that an identifier for a Person is optional ("termName": "Person.Identifier", "isMandatoryTerm": false). Using the dot notation allows us to do this, which the less explicit and more ambiguous "termName": "Identifier" wouldn't.

There was some debate about this during the expert review stage, and we did consider nesting SchemeTerms within each other, without the dot notation, as an alternative approach to representing those relationships (which also had its challenges). However, we agreed that it would be better to keep the structure relatively flat so that it's more usable by those who want to handle Latimer Core data in flatter structures such as spreadsheets. That being said, I don't think we're particularly wedded to the current dot notation, and if there's a better approach or formal convention that could be used instead we'd be very open to hearing about it!

Essentially, the SchemeTerm and SchemeMeasurementOrFact classes are intended to offer a serialisation-agnostic option within the LtC standard for defining/constraining/validating data in different Latimer Core schemes. However, those working in particular serialisations of LtC like JSON, RDF, and XML may want to use JSON Schema, Shape Expressions, XML Schema etc instead to create more detailed, nuanced LtC Scheme 'profiles' than the fairly basic provision within the LtC standard allows.

Apologies for the long response, but hope it provides some more context!

[baskaufs]

Just to clarify, the examples don't actually show up as invalid. Rather, a number of the triples are ignored. I think that's because many of the keys/predicates/names don't have namespaces or aren't defined in the context document.

Also, I'm not really saying that I think these necessarily need to be expressed as JSON-LD. In the TAG we've had discussion about creating some TDWG-wide guidelines for expressing TDWG metadata as JSON-LD, but that discussion hasn't progressed very far and there currently isn't any expectation that JSON-LD be used. I guess I would just suggest that you make it clear in the documentation that the examples aren't strictly JSON-LD, or else make them JSON-LD that serializes the metadata in the way you intend. I think it's perfectly fine for you to give examples using vanilla JSON if that's what you expect.

Similarly, I'm not aware that there's any kind of problem with the dot notation. I just wanted to clarify that it was a local solution. Your explanation about wanting to keep things as flat as possible makes sense.