search

netwerk-digitaal-erfgoed / makemyflix

Make your own Heritageflix
0 stars 0 forks source link

Issue with GraphDB and Fuseki SPARQL-endpoint #9

Closed coret closed 1 month ago

coret commented 1 month ago

When I run HeritageFlix with a GraphDB SPARQL-endpoint or a Fuseki SPARQL-endpoint (instead of TriplyDB) there are a Javascripts (screenshot below) indicating a HTTP 415 (Unsupported Meda Type) error and nothing is shown, see:

coret commented 1 month ago

@Andre > kun jij het request delen (los van HeritageFlix) die je doet en waarmee ook jij een HTTP 415 krijgt

ddeboer commented 1 month ago

Transferring to Makemyflix because we decided to continue work here.

aabelmann commented 1 month ago

De call die uit eindelijk werkte was: POST https://fuseki.coret.org/gtm/ raw body: categoryQuery zonder LIMIT _LIMIT_. De headers die ik meestuurde waren Content-Type: application/sparql-query en Accept: application/json.

Dit geeft JSON data terug maar de structuur van de JSON is nog niet zoals we verwachten.

pmaria commented 1 month ago

In principe schrijf de standaard Accept: application/sparql-results+json, voor, maar is wel de aanbeveling dat Accept: application/json zich ook zo moet gedragen. Je zou dat nog even kunnen testen. Anders moeten we even kijken naar de verschillen.

coret commented 1 month ago

@aabelmann dus in curl uitgedrukt wordt een request als hieronder gedaan? En wat verwacht je precies qua JSON?

curl -X POST -L https://fuseki.coret.org/gtm/  -H 'accept: application/json' \ 
  -H 'content-type: application/sparql-query' \
  --data-raw 'select * where {?s ?p ?o . } limit 10'

{ "head": {
    "vars": [ "s" , "p" , "o" ]
  } ,
  "results": {
    "bindings": [
      {
        "s": { "type": "uri" , "value": "https://www.goudatijdmachine.nl/def" } ,
        "p": { "type": "uri" , "value": "http://www.w3.org/1999/02/22-rdf-syntax-ns#type" } ,
        "o": { "type": "uri" , "value": "http://www.w3.org/2002/07/owl#Ontology" }
      } ,
...
aabelmann commented 1 month ago

Ik denk sowieso dan we aan de kant van MMF de Content-Type en Accept headers moeten gaan meesturen, dat doen we nu nog niet. Zodra dat gedaan is zitten we nog met de verschil in JSON response tussen een Triply Store en een Sparql response.

De basis van dit project is gedaan op basis van de response van https://api.data.netwerkdigitaalerfgoed.nl/datasets/heritageflix/churches-v1/services/churches-v1/sparql

Dit is een Triply store en de application/json die ik terug is heel erg compact:

[
  {
    "id": "https://sws.geonames.org/2756631/",
    "name": "Provincie Drenthe",
    "numberOfHeritageObjects": "499"
  },
  ... // Meer items
]

maar als je kijkt naar de response die je van SparQL krijgt, zoals @coret probeert, dan zie ik op end point: https://www.goudatijdmachine.nl/sparql/repositories/gtm de response:

{
  "head": {
    "vars": [
      "id",
      "name",
      "description",
      "numberOfHeritageObjects",
      "startDate",
      "endDate"
    ]
  },
  "results": {
    "bindings": [
      {
        "id": {
          "type": "uri",
          "value": "https://n2t.net/ark:/60537/bM3btQ"
        },
        "name": {
          "xml:lang": "nl",
          "type": "literal",
          "value": "Zoutmanplein"
        },
        "description": {
          "type": "literal",
          "value": "Genoemd naar Johan Arnold Zoutman (1724 - 1793), schout-bij-nacht en bevelhebber van de Nederlandse vloot tijdens de Vierde Engels-Nederlandse Oorlog. De in Reeuwijk geboren Zoutman trad op jeugdige leeftijd in dienst bij de marine van de Republiek der Zeven Verenigde Nederlanden. In 1779 werd hij benoemd tot schout-bij-nacht. Toen hij tijdens de Vierde Engels-Nederlandse Oorlog (1780 - 1784) een konvooi naar de Oostzee begeleidde, stuitte hij op een Brits eskader. De daarop volgende Slag bij de Doggersbank op 5 augustus 1781 eindigde feitelijk onbeslist maar Zoutman wist de Engelsen wel terug te dringen. In Nederland werd dit als een grote overwinning gevierd en Zoutman werd benoemd tot vice-admiraal. Kort voor zijn dood werd hij bevorderd tot luitenant-admiraal, de hoogste functie bij de admiraliteit."
        },
        "numberOfHeritageObjects": {
          "datatype": "http://www.w3.org/2001/XMLSchema#integer",
          "type": "literal",
          "value": "8"
        },
        "startDate": {
          "type": "literal",
          "value": "1920"
        },
        "endDate": {
          "type": "literal",
          "value": "1920"
        }
      }
    ]
  }

Dit is een hele andere structuur dan we op dit moment processen.

coret commented 1 month ago

Als ik eenzelfde request doen richting TriplyDB krijg ik wel andere JSON:

curl -X POST -L https://api.data.netwerkdigitaalerfgoed.nl/datasets/coret/ARKSorg/sparql \
  -H 'accept: application/json'  \
  -H 'content-type: application/sparql-query' \
  --data-raw 'select * where {?s ?p ?o . } limit 10'
[
  {
    "s": "https://arks.org/.info/ark:10113",
    "p": "https://schema.org/alternateName",
    "o": "USNAL"
  },
  {
    "s": "https://arks.org/.info/ark:10113",
    "p": "https://schema.org/dateCreated",
    "o": "2001-03-08"
  },
...

maar wat @pmaria zei: gebruik voor de accept application/sparql-results+json, dat is specifieke gedefinieerd JSON voor SPARQL resultaten.

curl -X POST -L https://api.data.netwerkdigitaalerfgoed.nl/datasets/coret/ARKSorg/sparql  -H 'accept: application/sparql-results+json'   -H 'content-type: application/sparql-query'   --data-raw 'select * where {?s ?p ?o . } limit 10'
{
  "head": {
    "vars": [
      "s",
      "p",
      "o"
    ]
  },
  "results": {
    "bindings": [
      {
        "s": {
          "type": "uri",
          "value": "https://arks.org/.info/ark:10113"
        },
        "p": {
          "type": "uri",
          "value": "https://schema.org/alternateName"
        },
        "o": {
          "type": "literal",
          "value": "USNAL"
        }
      },
...
coret commented 1 month ago

Snap alleen nog niet waarom zowel Fuseki als GraphDB een HTTP 415 geven, dat heb ik (via curl) nog niet kunnen reproduceren.

aabelmann commented 1 month ago

Met of zonder het opsturen van Headers?

aabelmann commented 1 month ago

Voor MMF moeten we de volgende aanpassingen maken. Meesturen van deze Request headers: Content-Type: application/sparql-query zodat de Bron partij weet wat we opsturen Accept: application/sparql-results+json zodat wij altijd hetzelfde formaat krijgen.

En dan moet de parsing iets aangepast worden om de nieuwe structuur te accepteren, dat zou niet zo ingewikkeld moeten zijn, het is iets meer diepte qua iteraties.

aabelmann commented 1 month ago

Okay, ik heb de headers toegevoegd en de parsing aangepast, lokaal zie ik gewoon resultaten voor al mijn test cases. Zelfs het namaken van https://makemyflix.netwerkdigitaalerfgoed.nl/goudse-straten werkt goed.

Daarentegen als ik nu kijk op https://makemyflix.netwerkdigitaalerfgoed.nl/goudse-straten zie ik dat meerdere requests aan het falen zijn. @ddeboer Kan jij zien wat er aan de hand is?

Ook heb ik even gecontroleerd en https://makemyflix.netwerkdigitaalerfgoed.nl/kerken werkt nog steeds.

coret commented 1 month ago

Ik kan me voorstellen dat mijn queries voor de goudse straten niet goed is (ik heb deze ook maar gemaakt op basis van een voorbeeld van Sablina zonder verder documentatie). Het zou mooi zijn als MMF een controle doet van de queries dat alle ?variabelen die vereist zijn in de SELECT voorkomen.

aabelmann commented 1 month ago

Ik kan me voorstellen dat mijn queries voor de goudse straten niet goed is (ik heb deze ook maar gemaakt op basis van een voorbeeld van Sablina zonder verder documentatie). Het zou mooi zijn als MMF een controle doet van de queries dat alle ?variabelen die vereist zijn in de SELECT voorkomen.

Ja voor goudse-straten heb ik al wat dingen gezien:

Dat allemaal gezegd is het gelijk een goede case om te zien waar het nu breekt. Zoals eerder gezegd, we zijn uit gegaan van HeritageFlix en de data daarvan was handpicked door Gertjan en Sjors. Ik ben groot voorstander van edge cases erin gooien, zo krijgen we betere producten.