Closed thewilkybarkid closed 4 years ago
Discovery at this least has two approaches:
The former is preferable.
I've had a play, and seems possible to do, but requires quite a bit of effort and work on the tooling (Alcaeus is geared towards JSON-LD at the moment).
That said, not sure it's worth it. There's little if anything else to be gained.
So, for now at least, it's probably easier and far simpler to used shared URI templates based on RDF types.
For example, configuration could look like:
http://schema.org/ScholarlyArticle: /articles/{doi}
So something with the rdf:type
of schema:ScholarlyArticle
will have a path based on its DOI.
As to what a DOI is, we'd recognise certain patterns, such as:
{
"@context": "http://schema.org/",
"type": "ScholarlyArticle",
"identifier": {
"type": "PropertyValue",
"propertyID": "DOI",
"value": "10.1000/182"
}
}
{
"@context": "http://schema.org/",
"type": "ScholarlyArticle",
"identifier": "doi:10.1000/182"
}
(In the first, feels like the schema:propertyID
should be an IRI rather than a literal...)
This is probably good enough for now.
But, in the future, when someone needs custom mappings, eg for:
http://schema.org/BlogPosting: /blog/{internal-id}/{slug}
A format like
mappings:
doi:
- type: https://schema.org/identifier
https://schema/org/propertyID: DOI
- type: https://schema.org/identifier
schema: doi
internal-id:
- type: https://schema.org/identifier
https://schema/org/propertyID: internal-id
slug:
- type: https://schema.org/identifier
https://schema/org/propertyID: slug
paths:
http://schema.org/ScholarlyArticle: /articles/{doi}
http://schema.org/BlogPosting: /blog/{internal-id}/{slug}
could be used. (This is getting similar to hydra:IriTemplate
.)
In the event that there's no DOI for a schema:ScholarlyArticle
, for example, or configuration is left out entirely (maybe you don't have pages for subjects), then the item is left unlinked.
far simpler to used shared URI templates based on RDF types
Is this a configuration format that we can foresee is global for various services? I can see it's needed from all the ones that need to generate a link, maybe we can envisage it as something that is identically configured for all frontends for simplicity, even if they don't necessarily make use of all the templates.
While they only need the ones they'd see at runtime, I'd imagine it's better to share the same configuration to reduce the burden.
Good to close? (So start with the simple configuration format.)
Good to close for me, with the actual configuration format (which properties for example) subject to iteration if it needs to change.