In many cases, an RDF view contains quad map patterns that maps all columns
of some table into triples in such a way that sets of triples made from different
columns are “obviously” pairwise disjoint and invoked IRI classes are bijections.
E.g., quad map patterns for RDF property tables usually satisfy these restrictions
because different columns are for different predicates and column values are
used as object literals unchanged. We are presently extending SPARUL
compiler and run-time in order to make such RDF views updatable.
The translation of a given RDF graph into SQL data manipulation statement
begins with extracting all SQL values from all calculatable fields of triples and
partitioning the graph into groups of triples, one group per one distinct extracted
primary key of some source table. Some triples may become members of more
than one group, e.g., a triple may specify relation between two table rows. After
integrity check, every group is converted into one insert or delete statement.
The partitioning of N triples requires O(N lnN) operations and keeps data in
memory so it’s bad for big dump/restore operations but pretty effecient for
transactions of limited size, like individual bookeeping records, personal FOAF
files etc.
of some table into triples in such a way that sets of triples made from different
columns are “obviously” pairwise disjoint and invoked IRI classes are bijections.
E.g., quad map patterns for RDF property tables usually satisfy these restrictions
because different columns are for different predicates and column values are
used as object literals unchanged. We are presently extending SPARUL
compiler and run-time in order to make such RDF views updatable.
The translation of a given RDF graph into SQL data manipulation statement
begins with extracting all SQL values from all calculatable fields of triples and
partitioning the graph into groups of triples, one group per one distinct extracted
primary key of some source table. Some triples may become members of more
than one group, e.g., a triple may specify relation between two table rows. After
integrity check, every group is converted into one insert or delete statement.
The partitioning of N triples requires O(N lnN) operations and keeps data in
memory so it’s bad for big dump/restore operations but pretty effecient for
transactions of limited size, like individual bookeeping records, personal FOAF
files etc.
No comments:
Post a Comment