ELD uitdagingen 1

Een van de geinteresseerden in Enterprise Linked Data loopt tegen de volgende uitdagingen aan in de praktijk:

  • Inkomende en uitgaande berichten op koppelvlakken (een Enterprise Service Bus) omzetten naar triples is moeizaam,
    • als je in de broncode geen domeinkennis wilt stoppen vanwege onderhoudbaarheid (bv. op een generieke manier vertalen van edifact naar triples)
    • als je gegevens wilt synchroniseren naar clients (smartphones en tablets) want dat is per definitie zelfbouw
  • We hebben 50.000 fatclients (business-logica in javascript runt in browser)
    • hoe ga je stukjes van de massief samenhangende graaf aan de backend uitdelen aan de clients
    • hoe ga je updates op deze stukjes terug synchroniseren naar de backend, en doorsturen naar andere clients indien relevant
    • atomair, rol-back etc.
  • Een rdf-store als ODS voor 15.000 concurrent gebruikers werkt technisch niet vanwege performance problemen
    • indexering is niet te dimensioneren (execution paths worden niet geoptimaliseerd)
    • open path-queries hebben te lange latency-tijden
    • Sparql is geen handige taal om over een graaf 'te wandelen' als je het pad dat je bewandelen wilt niet van te voren weet.


Deze uitdagingen zijn kort besproken op de Conceptual Friday van 9 januari.

LDP biedt een oplossing voor transacties met Linked Data en de W3C LDP Working Group werkt aan een verbeterde versie van LDP waarin ook authentication zit. Met de huidige versie van LDP moet je de beveiliging van data nog op HTTP-niveau regelen.

Indexering is nog lastig met Linked Data, maar grote partijen als IBM en Oracle werken gestaag aan verbeteringen op dit gebied.

Schaalbaarheid kan een issue zijn bij het werken met Linked Data. Er zijn verschillende manieren om dit op te lossen. Tussenstappen inbouwen in het proces, waarbij data geaggregeerd wordt in 'data containers' die beter te verwerken zijn in een volgende processtap (bijv. bij hele grote hoeveelheden sensordata). Partijen als Google en Facebook hebben dit opgelost door hun server park en hun data centers dubbel uit te voeren (meerdere data centers die kunnen bijspringen daar waar nodig).

In een volgende Conceptual Friday zouden wij deze uitdagingen nog meer in detail willen bespreken met een vertegenwoordiger van deze praktijkcase.