Improved performance of queries and cleaned them up

[mwigham]

Test plan:

• [ ] Look at each of the MOZ queries
• [ ] Is the query name ok?
• [ ] Is the query description ok?
• [ ] Is the query a useful example?
• [ ] Try the query in https://cat.apis.beeldengeluid.nl/. Does it do what you expect? (NB: the longest query takes about 45s to have a fully complete list of results)
• [ ] Are there other example queries you would find useful for this collection?
• [ ] I have made the choice now to make the queries simpler by using knowledge about the MOZ collection, e.g. that persons are only linked to programmes, not to series/seasons/scene descriptions. This makes the queries easier to read and understand, but less transferable to other collections. What do you think of this?

Improvements made are listed below:

• using direct equivalence for names instead of filtering
• listing the series triple first to limit the dataset to MOZ asap
• ordering results
• good descriptions in English
• removed unused PREFIX declarations
• limited person relations to those actually present in MOZ data
• only look at relations on programme level as MOZ doesn't have persons linked at other levels

Also added some additional queries

Fixes: https://github.com/beeldengeluid/comunica-web-client/issues/27

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Updated
comunica-web-client	✅ Ready (Inspect)	Visit Preview	Nov 1, 2022 at 6:21AM (UTC)

[mwigham]

Thank you very much for the review. I've checked in new versions according to the following:

• I've grouped by entity and name now. This is not necessary, as all GTAA entities have a unique pref label, but it is better not to rely on that.
• Statements with a common subject now use ';'
• The triple matching the series is deliberately first for performance reasons, so I have kept it that way
• There is only one series name used for this collection, so we can safely use "Muziekopnamen Zendgemachtigden (MOZ)"
• I have changed performer to artist
• I have improved the formatting

[wmelder]

For the MOZ Concerts query: Why not filter on the series ID? Also a property path seems to be useful here.

PREFIX sdo: <https://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

# Items uit de collectie Muziekopnamen Zendgemachtigden
SELECT DISTINCT ?program ?programName
WHERE {
  VALUES ?series {
    <http://data.beeldengeluid.nl/id/series/2101608030025711131>
  }
  ?program sdo:name ?programName ;
           sdo:partOfSeason /sdo:partOfSeries ?series
} LIMIT 100

[wmelder]

De queries hebben nu allemaal als comment:

# Toon alleen items die ook op GPP te bekijken/beluisteren zijn.

Dit is een copy/paste foutje.

[wmelder]

For "concerts linked to Beethoven" I would suggest to use the GTAA URI, instead of filter( contains("beethoven")). It would be less clear perhaps because the URI doesn't reveil the preflabel right away, but we should encourage users to use the GTAA URI's instead of doing string matches.

    # use the GTAA URI for "Ludwig von Beethoven"
    VALUES ?entity_uri {
        <http://data.beeldengeluid.nl/gtaa/80808>
    }

you automatically exclude all the other beethovens. There are 5 other matches when you use the query to search the thesaurus

@mwigham This query for items linked to Beethoven is very fast:

PREFIX sdo: <https://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

# Select items gelinkt aan Ludwig van Beethoven
SELECT DISTINCT ?program_uri ?programName 
WHERE {
  VALUES ?series {
    <http://data.beeldengeluid.nl/id/series/2101608030025711131>
  }
    # use the GTAA URI for "Ludwig von Beethoven"
    VALUES ?entity_uri {
        <http://data.beeldengeluid.nl/gtaa/80808>
    }
    ?program_uri sdo:name ?programName . 
?program_uri sdo:partOfSeason ?season . ?season sdo:partOfSeries ?series 
  {
    ?program_uri a sdo:CreativeWork ;
      (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer)/
      (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer) ?entity_uri  
  }
  UNION
  {
    ?program_uri sdo:isPartOfSeason ?season
    FILTER EXISTS {
    ?season  (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer)/
    (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer) ?entity_uri
  }
  }
  UNION
  {
    ?program_uri sdo:isPartOfSeason/sdo:isPartOfSeries ?series
    FILTER EXISTS {
      ?series  (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer)/
  (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer) ?entity_uri
    }
  }
  UNION
  {
    ?scene sdo:hasPart ?program_uri.
    FILTER EXISTS {
        ?scene  (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer)/
    (sdo:about|sdo:mentions|sdo:creator|sdo:contributor|sdo:actor|sdo:crew|sdo:performer) ?entity_uri 
  }
  } 
} LIMIT 100

[mwigham]

Thanks Willem.

My reason for matching on the names of the series and for Beethoven was readability, as these are example queries. We can change that to the IDs, as I think you are right, it is more important to teach them fast queries than to make the query more readable. In this case we won't then need the property path.

I don't see the GPP comment in any of the MOZ queries in this branch. Did you perhaps look at them online in the Comunica client itself? That won't be updated until this PR is merged.

[mwigham]

@wmelder I've checked in the changes, please take a look.

Re-reading some of your comments above, I think you may have reviewed old versions of the queries. Please read the files in the latest commit of this PR.

[wmelder]

I don't see the GPP comment in any of the MOZ queries in this branch. Did you perhaps look at them online in the Comunica client itself? That won't be updated until this PR is merged.

Yes, indeed I was foolishly just looking at the online client and not in the PR.

[wmelder]

@mwigham Queries are looking good!