ESWC2017 In-Use - Declarative Data Transformations for Linked Data Generation: the case of DBpedia
0 likes134 views
This document proposes an approach to declarative data transformations for linked data generation using RML (RDF Mapping Language) and FnO (Function Ontology). The current approaches have disadvantages like being restricted, uncombinable, coupled with implementations, and case-specific. The proposed approach uses aligned declarative schema and data transformations that are unrestricted, combinable, uncoupled from implementations, and case-independent. It has been implemented using RMLProcessor to connect to external parsing functions defined in FnO. This allows data transformations to be reused independently of the linked data generation framework or use case.
![direct mappings | successive steps
embedded data transformations| hard-coded
From original data to RDF with minimal change
e.g., CSVW, JSON(-LD)
Restricted: No schema nor data transformations
[[Honolulu]],
[[Hawaii]],
U.S.
dbr:
Honolulu
dbr:
Hawaii
?](https://image.slidesharecdn.com/2017-170601144335/85/ESWC2017-In-Use-Declarative-Data-Transformations-for-Linked-Data-Generation-the-case-of-DBpedia-13-320.jpg)
![{{Infobox president
|name = Barack Obama
|image = President Barack Obama.jpg
|office = President of the United States
|vicepresident = [[Joe Biden]]
|birth_place = [[Honolulu]], [[Hawaii]], U.S.
|term_start = January 20, 2009
|term_end = January 20, 2017
|birth_date = {{birth date and age|1961|8|4}}
|birth_name = Barack Hussein Obama II
…
extract](https://image.slidesharecdn.com/2017-170601144335/85/ESWC2017-In-Use-Declarative-Data-Transformations-for-Linked-Data-Generation-the-case-of-DBpedia-19-320.jpg)
![dbr:
Barack_
Obama
dbp:name
dbo:birthPlace
dbp:termStart
dbp:birthDate
[[Honolulu]],
[[Hawaii]],
U.S.
{{birth date and
age|1961|8|4}}
…
transform schema
Barack Obama
January 20, 2009](https://image.slidesharecdn.com/2017-170601144335/85/ESWC2017-In-Use-Declarative-Data-Transformations-for-Linked-Data-Generation-the-case-of-DBpedia-20-320.jpg)
ESWC2017 In-Use - Declarative Data Transformations for Linked Data Generation: the case of DBpedia
- 1. Declarative Data Transformations for Linked Data Generation: the case of DBpedia Ben De Meester, Wouter Maroy, Anastasia Dimou, Ruben Verborgh, and Erik Mannens Ghent University – imec – IDLab, Belgium
- 3. In loving memory of the Barack Obama examples in Semantic Web conferences
- 4. How to create Linked Barack? dbr: Barack_ Obama dbp:name dbo:birthPlace dbp:termStart dbp:birthDate "Barack Obama"@en dbr: Hawaii “20-01-2009” “04-08-1961” …
- 5. Linked Barack is based on schema and data
- 6. A specific case… Source handle WikiText Schema transformations use custom schema (DBpedia ontology) Data transformations parse manually entered input data https://en.wikipedia.org/wiki/Barack_Obama https://en.wikipedia.org/wiki/Leopold_II_of_Belgium
- 7. … needs a specific solution? … select extract transform schema transform data https://github.com/dbpedia/extraction-framework
- 8. Data transformations are hard-coded in the DBpedia EF Hard-coded means case specific coupled with the implementation You can’t use the DBpedia EF for other cases use the parsing functions outside the DBpedia EF
- 9. Declarative schema transformations are great Use-case independent Decoupled from the implementation
- 10. Declarative data transformations makes Linked Data generation 🚀🚀🚀🚀 Declarative schema transformations (i.e., semantic annotation rules) are great, so why not also for data transformations?
- 11. Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 12. Outline The current situation existing approaches direct mappings | successive steps embedded data transformations| hard-coded disadvantages What we provide our approach implementation
- 13. direct mappings | successive steps embedded data transformations| hard-coded From original data to RDF with minimal change e.g., CSVW, JSON(-LD) Restricted: No schema nor data transformations [[Honolulu]], [[Hawaii]], U.S. dbr: Honolulu dbr: Hawaii ?
- 14. direct mappings | successive steps embedded data transformations| hard-coded First data, then schema transformations (or vice versa) e.g., R2RML Restricted: depends on underlying system for data transformations e.g., SQL views for R2RML Uncombinable: combine transformations? e.g. , Born should return a date
- 15. direct mappings | successive steps embedded data transformations| hard-coded Tool supports limited set of data transformations e.g., OpenRefine Restricted: limited set of data transformations parsing is more than splitting a string or one regular expression Coupled: types of data transformations depend on the tool
- 16. direct mappings | successive steps embedded data transformations| hard-coded … select extract transform schema transform data https://github.com/dbpedia/extraction-framework DBpedia EF
- 18. select
- 19. {{Infobox president |name = Barack Obama |image = President Barack Obama.jpg |office = President of the United States |vicepresident = [[Joe Biden]] |birth_place = [[Honolulu]], [[Hawaii]], U.S. |term_start = January 20, 2009 |term_end = January 20, 2017 |birth_date = {{birth date and age|1961|8|4}} |birth_name = Barack Hussein Obama II … extract
- 20. dbr: Barack_ Obama dbp:name dbo:birthPlace dbp:termStart dbp:birthDate [[Honolulu]], [[Hawaii]], U.S. {{birth date and age|1961|8|4}} … transform schema Barack Obama January 20, 2009
- 22. Hard-coded: disadvantages Coupled: data tranformations only usable in that implementation Case-specific: only for one use case
- 23. Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 24. Disadvantages of current approaches Restricted Uncombinable Coupled Case-specific
- 25. What do we want? Unrestricted data transformations Combinable schema and data transformations Uncoupled with the implementation Case-independent solution
- 26. Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 27. Aligned declarative schema and declarative data transformations Aligned combine data and schema transformations Declarative data transformations no restriction re-use outside generation framework Aligned declaratives not use case, nor implementation specific
- 28. Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- 29. Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- 30. Declaratives Declarative schema transformations source agnostic, schema agnostic RDF Mapping Language (RML) | http://RML.io Declarative data transformations implementation agnostic Function Ontology (FnO) | http://FnO.io Aligned FunctionMap / functionValue Connection between RML and FnO
- 31. RML mapping source subject dbp:birthDate birth_date WikiText dbr:{wiki_label} predicate reference Person_ Mapping birthDate_ Mapping dbr: Barack_ Obama dbp:birthDate {{birth date and age|1961|8|4}}
- 32. FnO mapping executes inputString DBpedia_ date_parser birth_date DBP_Parsing_ Function “04-08-1961”
- 33. Separate RML and FnO source subject dbp:birthDate birth_date WikiText dbr:{wiki_label} predicate reference Person_ Mapping birthDate_ Mapping executes inputString DBpedia_ date_parser birth_date DBP_Parsing_ Function
- 34. Aligned RML and FnO source subject dbp:birthDate executes inputString WikiText dbr:{wiki_label} DBpedia_ date_parser birth_date predicate DBP_Parsing_ Function Function Map Person_ Mapping birthDate_ Mapping
- 35. Aligned RML and FnO source subject dbp:birthDate executes inputString WikiText dbr:{wiki_label} DBpedia_ date_parser birth_date predicate DBP_Parsing_ Function Function Map Person_ Mapping birthDate_ Mapping
- 36. Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- 37. Practical - Implementation RMLProcessor include WikiText extractor support FunctionMap / functionValue connect to FunctionProcessor FunctionProcessor dynamically load and call function External DBpedia Parsing functions
- 38. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 39. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 40. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 41. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 42. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 43. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 44. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 45. … RML_FnO-doc Function Processor … select extract transform schema + transform data
- 46. Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 47. Our approach generates the same DBpedia data, and: You don’t depend on the implementation You don’t depend on the use case DBpedia parsing functions can be reused elsewhere Data transformations can use existing or new external libraries
- 48. See it in action! Booth 49 https://fnoio.github.io/dbpedia-demo/ https://github.com/RMLio/RML-Mapper/tree/extension-fno https://github.com/FnOio/function-processor-java https://github.com/FnOio/dbpedia-parsing-functions-scala
Editor's Notes
- #3: I’d like to give a small warning here.. Even though numerous people told us not to…
- #4: I am going to use barack obama. It’s probably one of the last times we can use our mascot
- #5: Barack’s data in DBpedia…
- #7: schema is very specific (so are the schema transformations) data tfs are very specific
- #8: Is mostly generated using the DBpedia EF (specifically for the infoboxes): relevant pages are selected, the infoboxes are extracted, the values are put in a certain schema (so schema tfs), finally, the values themselves are transformed (so data transformations).
- #9: However, they are embedded in the EF. That’s a pity, because dbpedia is so widely used etc. The EF has been tested on 1000s of wikipages, but you can’t use it for other use cases, and you can’t use the parsing functions outside the DBpedia EF. as we will see later, no current solutions can cope with more advanced data transformations
- #10: More clear
- #11: So, declarative schema transformations exist. They make generating linked data possible without depending on implementation or use case. Great. However, due to high data tfs demands, current generation approaches cannot be used. What about declarative data tfs?! That would be awesome!
- #14: split?
- #17: Is mostly generated using the DBpedia EF (specifically for the infoboxes): relevant pages are selected, the infoboxes are extracted, the values are put in a certain schema (so schema tfs), finally, the values themselves are transformed (so data transformations).
- #18: so, you have all pages
- #19: you select the ones with relevant infoboxes
- #20: The infoboxes are extracted (just using following as simplified examples)
- #21: use custom mapping doc for the schema tfs
- #22: Then, the data is parsed to get ‘good data’. This is a very important part of DBpedia, as the data values are entered in wikipedia (so manually), the input data can be very diverse, typo’s different ways of writing things. A large deal of effort has been done into creating these parsing functions, and they are really good.
- #31: not the only solution
- #34: instead of use raw value directly…
- #35: use value after being parsed by underlying function
- #36: use value after being parsed by underlying function
- #38: support wikitext: was easy (RMLProcessor is made for that, natural thing to do)
- #47: [ ] 2 zinnen recap