Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restructure of openDS datamodels and new versions #97

Merged
merged 5 commits into from
Jun 17, 2024

Conversation

samleeflang
Copy link
Contributor

Ok massive changes.

  • All folder names to singular (before it was inconsistent)
  • Version has moved a level down, this way we can have a version for each type and not for all types together
  • Datamodel changes for:
    • Source system
    • Mapping
    • Machine Annotation Service
    • Annotations
  • Captured and changed datamodel of:
    • CreateUpdateTombstone Event
  • Update Dockerfile to include lastest endpoint

Copy link
Contributor

@southeo southeo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🌟

COPY fdo-type/virtual-collection/0.1.0/schema schema-root/schemas/fdo-type/vitual-collection/0.1.0

# Versioned FDO Type schemas
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Latest, not versioned

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@@ -0,0 +1,55 @@
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://schemas.dissco.tech/schemas/developer-schema/annotation/0.2.0/annotation-for-mas.json",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should be annotation-event.json

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

"type": "array",
"items": {
"type": "object",
"properties": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please add additionalproperties = false

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

"description": "The type of the object, in this case ods:BatchMetaData",
"const": "ods:AnnotationEvent"
}
},
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does this need an @id property?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so, what would it be, the jobID?

"https://doi.org/21.T11148/894b1e6cad57e921764e"
]
},
"oa:hasSelector": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1 - if this isn't an array, do we need the hasXXX structuring?
2 - I don't think we can change an external namespace

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this applies to oa:hasTarget, ac:hasROI, oa:hasBody

If we need to add the hasXXX structuring, I don't think we can change the name of the term. We'd probably have to nest it like we do with specimens

ods:hasSelector: {
    "oa:selector":{
        ...
  }
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes I thought about this but we cannot change an externally borrowed term. What we could do is create our own term ods:Selector and then map it but that is ugly and confusing as well. I think we are just stuck with the oa term which doesn't fit our naming convention.
So 1. no we wouldn't need a hasXXX structure but we got 2. this is how this is called in oa

"@type": {
"type": "string",
"description": "The type of the object, in this case oa:Annotation",
"const": "oa:Annotation"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we call it oa:Annotation if we've made changes? Maybe ods:Annotation?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. good point. technically, this const is not in the oa name space.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed this to ods:Annotation

"additionalProperties": false
},
"oa:hasBody": {
"type": "object",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

might not be able to use hasXXX here either

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Taking over the hasBody over from oa, I think that is the better choice here

@@ -1,12 +1,12 @@
{
"$schema": "https://json-schema.org/draft/2020-12/schema",
"$id": "https://schemas.dissco.tech/schemas/annotations/0.1.0/annotation-event.json",
"description": "Object sent to annotation processing service from core backend. Internal use only.",
"$id": "https://schemas.dissco.tech/schemas/developer-schema/annotation/0.1.0/annotation-event.json",
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what is "deverloper-schema" here?

Copy link
Contributor Author

@samleeflang samleeflang Jun 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That are schema's used for systems who want to interact to our system. In this case for example the MAS. The MAS doesn't needs to produces annotations which are slightly different than what the annotations endpoint produces. For example, the MAS does not need to indicate the generator part as this gets added by the annotation-processing-service. However, if the MAS supports batch, it does need to provide the batching information. So we put these schemas under deverloper-schema to indicate that only developers building on DiSSCo platform need these schemas.

"@type": {
"type": "string",
"description": "The type of the object, in this case oa:Annotation",
"const": "oa:Annotation"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. good point. technically, this const is not in the oa name space.

"description": "The type of the object, in this case ods:BatchMetaData",
"const": "ods:BatchMetaData"
},
"ods:placeInBatch": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

placeInBatchqueue be better?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Don't think this is related to the position in the queue, @southeo can probably better answer this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are two components of an AnnotationEvent sent from the MAS to the processing service: BatchMetadata and the Annotations. Both of these can be lists, however, so the processing service needs a way to figure out which Annotation is associated with which BatchMetadata. The field placeInBatch is the value that links these two fields.

(The batch metadata are the terms and values used to determine the search queries for to create annotations)

"type": "string",
"description": "The full jsonPath of the field being annotated. Following: https://goessner.net/articles/JsonPath/index.html#e2",
"examples": [
"$.occurrences[0].location.dwc:country"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Update this example? Since occurrences is not present any more in the new data model

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed this everywhere

"type": "string",
"description": "The full jsonPath of the class being annotated. Following: https://goessner.net/articles/JsonPath/index.html#e2",
"examples": [
"$.occurrences[0].location.georeference"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also update this example since occurrences is not in the data model anymore

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

"Other Geodiversity",
"Unclassified"
],
"$.occurrences[*].location.dwc:locality": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, occurrences does not exist anymore right

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

"Other Geodiversity",
"Unclassified"
],
"$.occurrences[*].location.dwc:locality": [
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, occurrences does not exist anymore right

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed

Copy link
Contributor

@TomDijkema TomDijkema left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🍌

@samleeflang samleeflang merged commit 78a489a into master Jun 17, 2024
1 check passed
@samleeflang samleeflang deleted the feature/all-objects-to-0.3.0 branch June 17, 2024 12:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants