This was created following the LinkML tutorial
projectpost.yaml
contains the LinkML schema for a project post. There are separate classes forProjectPost
,File
andFileLocation
that 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.rdf
and 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
order
property. - 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
order
could 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:hasGeometry
with ageo:asWKT
serialization. - Relevant LinkML issue to allow distinguishing between a
set
andlist
: linkml/linkml#221
data.json
contains 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.