Add, extend and refactor SPARQL queries

[edwardanderson]

This PR extends the Search Links area of the documentation by adding and extending SPARQL queries. It also refactors some of the existing queries.

I'm proposing to change the variable templating pattern a little, so that the examples are natively valid SPARQL but can also be used as string templates in code. This is done by using the $ character for variables which can be templated, which according to 4.1.3 Syntax for Query Variables in SPARQL 1.1 Query Language is as equally valid as ?. For example, instead of:

SELECT DISTINCT ?activity
WHERE {
  BIND (<%current%>AS ?group)
  ?activity crm:P14_carried_out_by ?group .
}

I propose...

SELECT DISTINCT ?activity
WHERE {
  ?activity crm:P14_carried_out_by $current .
}

... or potentially if we prefer the BIND as an entrypoint...

SELECT DISTINCT ?activity
WHERE {
  BIND($current AS ?group)
  ?activity crm:P14_carried_out_by ?group .
}

... so that the query can be executed as is, validated, linted, or constrained by replacing the template variable. In Python, for example:

>>> from string import Template
>>> template = Template('?activity crm:P14_carried_out_by $current .')
>>> template.safe_substitute(current='<http://example.org/activity/1>')
'?activity crm:P14_carried_out_by <http://example.org/activity/1> .'

Other languages could use a regular expression like (\$\w+).

Aside from these changes to the templating pattern, this PR also provides queries in an ontologically symmetrical form. Thus both the direct and inverse properties are tested, with UNION preferred over OPTIONAL for performance reasons.

PREFIX crm: <http://www.cidoc-crm.org/cidoc-crm/>

SELECT DISTINCT ?activity
WHERE {
  {
    ?activity crm:P14_carried_out_by $current .
  } UNION {
    $current crm:P14i_performed ?activity .
  }
}

I would like to consider with the community whether this symmetry is always necessary. I think it is useful for querying knowledge graphs which implement both the Linked Art Model and API document partitions (because part/whole and member/has_member are documented patterns), but is it perhaps going too far by testing the inverse of pure CRM patterns that Linked Art doesn't describe? For example, crm:P98_brought_into_life isn't a documented Linked Art property:

WHERE {
  {
    ?person crm:P98i_was_born ?birth .
  } UNION {
    ?birth crm:P98_brought_into_life ?person .
  }
}

A further question here is whether or not the inverse properties should be provided in the query explicitly, or whether instead the ontologies (CRM, LA, SKOS, etc.) should be side-loaded and inferred against.

Relates to #763.

[edwardanderson]

Enumerated points for future discussion:

1. Shall we always use a BIND($current AS ?...) entrypoint pattern for more expressive variable names inside the query and more obvious templating?
2. Shall we also look at SPARQL Anything's Query templates and variable bindings in case there are better established patterns for variable templating?
3. Should ontological symmetry crm:P98i_was_born|^crm:P98_brought_into_life be compliant with pure CRM (as in the JSON-LD @context) or only where specified by the Linked Art model or API documentation/schema (allow part|part_of but not classified_as|type_of)?
4. Should queries always (or sometimes) account for event partitions?

   ?object crm:P108i_was_produced_by/(crm:P9_consists_of|crm:P9i_forms_part_of)*/crm:P7_took_place_at ?place

5. Shall we separate the work* queries into visualWork* and textualWork* ones?

[azaroth42]

Wonderful, thank you Edward. Waiting for 1.0.1