Page-level routing

[thewilkybarkid]

The homepage will have links to article pages, but how does it know they exist/what the path is? Feels like the same hypermedia approach would solve this, so an article-page service could also expose an API with entries like:

  {
    "@context": "http://schema.org/",
    "id": "http://example.com/articles/abcde",
    "type": "ItemPage",
    "mainEntity": "http://article-store.example.com/some/path/to/12345"
  }

So a hypermedia knows to link to http://example.com/articles/abcde on a teaser for article http://article-store.example.com/some/path/to/12345 by doing a lookup operation.

This would allow turning off/on of things like subject pages, article type pages etc by running (or not) the relevant page service.

Also means it's easy to customise what routes are (e.g. maybe you want to use a DOI in the path, or some other local identifier).

This is another layer of complexity though, and is probably a step too far...

[thewilkybarkid]

Discovery at this least has two approaches:

1. Embed Hydra details in the HTML
2. Have a separate API

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.)

[thewilkybarkid]

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.

[giorgiosironi]

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.

[thewilkybarkid]

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.

[thewilkybarkid]

Good to close? (So start with the simple configuration format.)

[giorgiosironi]

Good to close for me, with the actual configuration format (which properties for example) subject to iteration if it needs to change.