Advertisement
Check these out next
ESWC2017 In-Use - Declarative Data Transformations for Linked Data Generation: the case of DBpedia
Jun. 1, 2017•0 likes•132 views
0 likes
Be the first to like this
Show More
views
Total views
0
On Slideshare
0
From embeds
0
Number of embeds
0
Download to read offline
Report
Data & Analytics
Mapping languages allow us to define how Linked Data is generated from raw data, but only if the raw data values can be used as is to form the desired Linked Data. Since complex data transformations remain out of scope for mapping languages, these steps are often implemented as custom solutions, or with systems separate from the mapping process. The former data transformations remain case-specific, often coupled with the mapping, whereas the latter are not reusable across systems. In this paper, we propose an approach where data transformations (i) are defined declaratively and (ii) are aligned with the mapping languages. We employ an alignment of data transformations described using the Function Ontology (FnO) and mapping of data to Linked Data described using the rdf Mapping Language (RML). We validate that our approach can map and transform DBpedia in a declaratively defined and aligned way. Our approach is not case-specific: data transformations are independent of their implementation and thus interoperable, while the functions are decoupled and reusable. This allows developers to improve the generation framework, whilst contributors can focus on the actual Linked Data, as there are no more dependencies, neither between the transformations and the generation framework nor their implementations.
Ben De MeesterFollow
Researcher at imecAdvertisement
Advertisement
Advertisement
Recommended
2011 05-02 linked data introvafopoulos
2011 05-01 linked datavafopoulos
ACOMP_2014_submission_70David Nguyen
DBpedia: A Public Data Infrastructure for the Web of DataSebastian Hellmann
Introduction to the Data Web, DBpedia and the Life-cycle of Linked DataSören Auer
Linked Data (1st Linked Data Meetup Malmö)Anja Jentzsch
ESWC2017 In-Use - Declarative Data Transformations for Linked Data Generation: the case of DBpedia
- 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
- In loving memory of the Barack Obama examples in Semantic Web conferences
- 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” …
- Linked Barack is based on schema and data
- 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
- … needs a specific solution? … select extract transform schema transform data https://github.com/dbpedia/extraction-framework
- 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
- Declarative schema transformations are great Use-case independent Decoupled from the implementation
- Declarative data transformations makes Linked Data generation 🚀🚀🚀🚀 Declarative schema transformations (i.e., semantic annotation rules) are great, so why not also for data transformations?
- Outline The current situation existing approaches disadvantages What we provide our approach implementation
- Outline The current situation existing approaches direct mappings | successive steps embedded data transformations| hard-coded disadvantages What we provide our approach implementation
- 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 ?
- 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
- 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
- direct mappings | successive steps embedded data transformations| hard-coded … select extract transform schema transform data https://github.com/dbpedia/extraction-framework DBpedia EF
- select
- {{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
- 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
- dbr: Hawaii dbr: Barack_ Obama dbp:name dbo:birthPlace dbp:termStart dbp:birthDate "Barack Obama"@en dbr: Hawaii “20-01-2009” “04-08-1961” … transform data ……
- Hard-coded: disadvantages Coupled: data tranformations only usable in that implementation Case-specific: only for one use case
- Outline The current situation existing approaches disadvantages What we provide our approach implementation
- Disadvantages of current approaches Restricted Uncombinable Coupled Case-specific
- What do we want? Unrestricted data transformations Combinable schema and data transformations Uncoupled with the implementation Case-independent solution
- Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 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
- Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- 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
- 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}}
- FnO mapping executes inputString DBpedia_ date_parser birth_date DBP_Parsing_ Function “04-08-1961”
- 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
- 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
- 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
- Outline The current situation existing approaches disadvantages What we provide our approach implementation declaratives | tools
- Practical - Implementation RMLProcessor include WikiText extractor support FunctionMap / functionValue connect to FunctionProcessor FunctionProcessor dynamically load and call function External DBpedia Parsing functions
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- … RML_FnO-doc Function Processor … select extract transform schema + transform data
- Outline The current situation existing approaches disadvantages What we provide our approach implementation
- 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
- 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
- I’d like to give a small warning here.. Even though numerous people told us not to…
- I am going to use barack obama. It’s probably one of the last times we can use our mascot
- Barack’s data in DBpedia…
- schema is very specific (so are the schema transformations) data tfs are very specific
- 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).
- 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
- More clear
- 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!
- split?
- 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).
- so, you have all pages
- you select the ones with relevant infoboxes
- The infoboxes are extracted (just using following as simplified examples)
- use custom mapping doc for the schema tfs
- 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.
- not the only solution
- instead of use raw value directly…
- use value after being parsed by underlying function
- use value after being parsed by underlying function
- support wikitext: was easy (RMLProcessor is made for that, natural thing to do)
- [ ] 2 zinnen recap
Advertisement