This was created following the LinkML tutorial
projectpost.yamlcontains the LinkML schema for a project post. There are separate classes forProjectPost,FileandFileLocationthat utilize standard GeoSPARQL + WKT conventions.- This schema sets the default prefix/context to
regenschema, but uses a few DC terms for most of the semantic modelling. - Project post files are referenced via the Regen IRI of the anchored data
?post dct:references regen:1111.rdfand the same Regen IRI is used as the subject for metadata about the fileregen:111.rdf dct:title "File name"- This seems like the simplest approach for referencing files. There is no complexity of other blank or list nodes that the post uses to reference the files. Odering of files is not deterministic but could be solved with a separate
orderproperty. - More practically, I wonder if the order of files may be preserved simply by fact that the resolver (likely) returns the same JSON-LD document that was anchored. Would this work in the short term? If file order is important more semantic importance (eg when indexing/aggregating rdf data into a larger graph) then
ordercould be added.
- This seems like the simplest approach for referencing files. There is no complexity of other blank or list nodes that the post uses to reference the files. Odering of files is not deterministic but could be solved with a separate
- Blank nodes are only generated in RDF serialization to properly model the location
geo:hasGeometrywith ageo:asWKTserialization. - Relevant LinkML issue to allow distinguishing between a
setandlist: linkml/linkml#221
data.jsoncontains a simple JSON definition of a project post.- To validate + convert to json-ld run:
linkml-convert -s post.yaml data.json -t json-ld, This will yield the example injsonld-data.jsonld - JSON Schema + SHACL can be generated, attaching the SHACL here, but didn't investigate how this could be further constrained.