26-07-2022 Metadata ON AIR

Cosa ho fatto

Novità relative all’API di OC Meta

L’API di OC Meta è pronta. La potete provare qui: https://oc-meta-test.arcangelomassari.it/api/v1 (l’host è il PC in camera mia, probabilmente non sarà sempre acceso. Forse sposterò il tutto su un RaspberryPi perché mi piacerebbe fare un po’ di beta testing).

  • metadata
    • L’operazione metadata gestisce ora anche id multipli per autori ed editor.
    • Risolto un bug per cui non venivano ritornati id ulteriori rispetto a quelli indicati come input dell’operazione.
  • Ho implementato e testato le operazioni author/{orcid} ed editor/{orcid}
  • Ho implementato la ricerca testuale sui campi title, author, editor, publisher, page, issue, volume, venue. Inoltre, è possibile specificare “all” come campo per cercare su tutti i campi.

    • Tale ricerca avviene tramite l’operazione /search/{fields}/{text}

      • È possibile specificare più di un campo, separati da doppio trattino basso, ad esempio /search/author__editor/Peroni

    • Per ottenere questo risultato, una funzione di preprocess genera frammenti di query testuali specifiche a seconda del campo, che vengono poi integrate nella query principale in modo da filtrare le entità di cui si vogliono ottenere i metadati.

    • La ricerca testuale sui campi author ed editor avviene con una sintassi specifica.

      • Ecco tutte le possibilità:

        • familyName,givenName (e.g., Peroni,Silvio)

        • familyName, (e.g., Peroni,)

        • ,givenName (e.g., ,Silvio)

        • name (e.g. Research Centre for Open Scholarly Metadata)

      • Adottare questa sintassi permette di risolvere due problemi:

        • ⚠️ Problema 1. Senza una sintassi che specifichi cosa è un foaf:familyName, foaf:givenName e foaf:name, il risultato conterrebbe l’unione di tutte queste possibilità e sarebbe impreciso.
        • ⚠️ Problema 2. Fare l’unione di tutti i risultati sui foaf:familyName, foaf:givenName e foaf:name rende la query molto lenta.

    • Per utilizzare i predicati speciali di Blazegraph all’interno di sotto-query bisogna racchiudere i triple pattern che utilizzano questi predicati entro l’operazione SERVICE

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13

      SELECT ...
      WHERE {
      ...
      	{SELECT ?res 
      	WHERE {
      		?res <http://purl.org/dc/terms/title> ?tsTitle.
      			SERVICE <http://www.bigdata.com/rdf/search#search> {
      				?tsTitle bds:search "Peroni";
      			  bds:matchAllTerms 'true'.
      			}
      	}}
      }}

      Questa informazione non è più presente nella documentazione di Blazegraph, perché era presente in una documentazione che ora è offline. L’unica traccia che ho trovato è in una discussione su Stackoverflow.

    • La ricerca testuale sembra non funzionare sul campo date, perché la data non è una stringa e credo che Blazegraph non indicizzi i letterali di tipo xsd:gYear, xsd:gYearMonth o xsd:gDate.

    • Non ho implementato la ricerca testuale sul campo id perché mi è sembrata ridondante rispetto all’operazione metadata

    • Le ricerche testuali su ciascuno dei campi menzionati sono state testate.

  • Ho testato tutte le operazioni su un triplestore di 161,267,659 di triple per mettere alla prova l’efficienza delle query.

    • Mi sono accorto che riscrivendo le query concentrando tutti i JOIN all’entità bibliografica da identificare all’interno della sotto-query la query è enormemente più veloce. Al contrario, se parte dei triple pattern è nella query interna e parte in quella esterna, sebbene la query esterna debba fare riferimento alla stessa entità di quella interna, la query è molto più lenta.

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      17
      18
      19
      20
      21
      22
      23
      24
      25
      26
      27
      28
      29
      30
      31
      32
      33
      34
      35
      # Lenta
      SELECT ?res ?type
      WHERE {
        {SELECT ?res # La query interna viene risolta per prima
         	WHERE {
          ?res pro:isDocumentContextFor ?knownEditor.
          ?knownEditor pro:withRole pro:author;
                       pro:isHeldBy ?knownPerson.
          ?knownPerson datacite:hasIdentifier ?knownPersonIdentifier.
          ?knownPersonIdentifier datacite:usesIdentifierScheme datacite:orcid;
                                 literal:hasLiteralValue "0000-0002-4765-6547".
        }}
        **?res a ?type. # Triple pattern nella query esterna**
      }

      # Veloce
      SELECT ?res ?type
      WHERE {
        {SELECT ?res ?type
         	WHERE {
          ?res pro:isDocumentContextFor ?knownEditor.
          ?knownEditor pro:withRole pro:author;
                       pro:isHeldBy ?knownPerson.
          ?knownPerson datacite:hasIdentifier ?knownPersonIdentifier.
          ?knownPersonIdentifier datacite:usesIdentifierScheme datacite:orcid;
                                 literal:hasLiteralValue "0000-0002-4765-6547".
      		**?res a ?type. # Triple pattern dentro la query interna**
        }}
      }

      # La query veloce impiega 84 ms, quella lenta fa crashare il triplestore

      # Forse la query interna viene rieseguita se una variabile all'esterno
      # richiama uno dei risultati della query interna?

    • Alla luce di questa evidenza, ho inizialmente riscritto tutte le query concentrando nella query interna il BGP relativo all’entità da identificare e mettendo nella query esterna solo le operazioni di concatenazione.

    • Per evitare che Blazegraph ripeta più volte la query per identificare le risorse bibliografiche rilevanti ho utilizzato una named subquery, ovvero un’estensione per pre-computare un insieme di soluzioni da riutilizzare più volte nella query.

      • Questa modifica ha aumentato drasticamente la velocità di tutte le operazioni, in particolare quelle che utilizzano testuale.
  • Ho implementato le funzioni preprocessing e postprocessing in modo che utilizzino solo librerie built-in di Python, per una maggiore compatibilità e interoperabilità.

Cose brutte che saranno ineluttabilmente in OC Meta

Domande

Tu vuo far el phdino
26-07-2022 Metadata ON AIR
https://arcangelo7.github.io/p/a5c16a2f4aff4a8f8197ff3afa16422a/
Author
Arcangelo Massari
Posted on
July 25, 2022
Licensed under