Open pbuttigieg opened 11 months ago
The exchange of some sample metadata will be subject to a wide range of license and restriction clauses. Be prepared for CARE alignment and more advanced provenance tracking in this pattern, which can be generalised across others
@fils should the PR target the thematics in the book directory or is the new publishing flow instantiated? Where should I create the pattern for the PR?
For archaeological materials from Open Context (https://opencontext.org), we want to make sure that aggregators (search engines, ecommerce players) DO NOT interpret archaeological materials as items involved in commerce. We actively want to work AGAINST archaeological materials circulating in commerce (the antiquities trade is very destructive), so there needs to be some clear signal in the metadata that such materials are not commercially appropriate.
For archaeological materials from Open Context (https://opencontext.org), we want to make sure that aggregators (search engines, ecommerce players) DO NOT interpret archaeological materials as items involved in commerce. We actively want to work AGAINST archaeological materials circulating in commerce (the antiquities trade is very destructive), so there needs to be some clear signal in the metadata that such materials are not commercially appropriate.
@ekansa many thanks - there are properties where conditions of access and usage parameters can be defined.
What sort of statement or link would you like as the value of such a field?
there's a proposed schema.org implementation of the iSamples metadata scheme, its in a branch in our metadata Github repo: https://github.com/isamplesorg/metadata/tree/develop/notes/schemaOrg. Its based on schema:Thing, and uses properties from a variety of entities, so the validator throws some warnings, but no errors.
the mapping is also documented here: https://docs.google.com/document/d/1EZDeulvglKVphlo8cHkZAQ4xYr7-yWMF
@datadavev - tagging you for the iSamples federation, see also #388
@pbuttigieg is there anything you'd like from me to update with Open Context itself?
nudging this along, I reviewed the sdo:product template that @pbuttigieg pointed to in https://github.com/iodepo/odis-arch/issues/376#issue-2030852850. Here are some note comparing to the current iSamples schema.org material sample record implementation draft with that template:
but are not used or defined differently in iSamples ...
"disambiguatingDescription": ?? not in iSamples scheme, not clear how its supposed to be used in this context
"productionDate": in iSamples this is startDate, endDate for sampling event
"releaseDate": This is the subjectOf/sdDatePublished in iSamples draft
these size related properties were considered but too rarely recorded, and decision was to not include in base metadata scheme; proposal was to use in an additionalProperty element, but iSamples does not currently implement. -- "size": -- "weight": -- "width":
"image": iSamples related link, with linkRelationship like "image of sample"
"mainEntityOfPage": iSamples relatedLink
"subjectOf" iSample relatedLink
"sameAs": alternate identifiers are listed in the isamples identifier array.
"additionalProperty": Considered in early model development, but not implemented yet.
sdo:Thing, sdo:DefinedTerm, sdo:DefinedTermSet,sdo:CreativeWork, sdo:Event, sdo:DigitalDocument, sdo:Role, sdo:PropertyValue, sdo:GeoCoordinates, sdo:LinkRole, sdo:EntryPoint
Pull request created here: https://github.com/iodepo/odis-in/pull/31
"dcterms:conformsTo" is used to indicate specifications and profiles that a data conforms to or that the metadata conformsTo, depending on the context.
This will be moved to a JSON-LD file (J2) that describes the JSON-LD file about the sample itself (J1).
We can link to J2 from J1 using "subjectOf" in J1.
Working with the Sampling Nature RCN, and leveraging work done by Open Context on JSON-LD exchange of sample (meta)data (e.g. this record), we should create a pattern for samples using schema.org semantics and test it against some of the examples gathered during the RCN meetings.
First instinct - develop from the
Product
type and nest domain-level semantics inadditionalProperty
keys. We've alraedy done the groundwork for this here, so it's a question of adapting this to some sample examples from OpenContextxref #309 #125