1.7.1

Release Notes

This is a minor release for the upcoming 1.8. It contains some minor bug fixes and code improvement in the programming interface.

API Changes

• Method getValueList() in QueryResult is depreciated and got replaced by getValueArray().
• Class Database is able to give the current SQL dialect using getDialect() method.

1.7

Release Notes:

• Improved Data Type Handling
  There have been a lot of bug fixes for handling data types. Users can override data types and the system will ensure a safe conversion, including to add cast function in SQL query automatically. The system support almost all primitive and derived XML datatypes (see table conversion below). However, data type reasoning is not available.
• Support SPARQL STR
  More support on SPARQL syntax. Users can use STR expression to get the string representation of a given literal in SPARQL query.

API Changes

• Class Value is no longer available. Iterating a value list will return you either a Literal or Uri object. Both are different classes to represent typed-value and object-value, respectively.
• Use getType() to determine the type of a Value object as an alternative way from using instanceof condition.
• When the JDBC Result Set returns null then the system produces a null object as well in the value list. Therefore, you need to take care null object while iterating the value list, especially when dealing with queries that use OPTIONAL expression.
• Class QueryReturnMetadata has been replaced by QueryMetadata. The implementation is different especially the new class can determine the select item should be a literal-value or an object-value.
• DataTypeException is a runtime exception. No need to try-and-catch it anymore.
• The prefix manager has a copy(Map<String,String>) method to store prefix-namespace pairs in batch.
• XmlTypeToSqlType defines type conversion XSD --> SQL in the following. (Note that the SQL types are represented by java.sql.Types constants.

XSD	SQL	XSD	SQL
xsd:string	Types.VARCHAR	xsd:unsignedByte	Types.SMALLINT
xsd:boolean	Types.BOOLEAN	xsd:double	Types.DOUBLE
xsd:decimal	Types.DECIMAL	xsd:float	Types.FLOAT
xsd:long	Types.BIGINT	xsd:dateTime	Types.TIMESTAMP
xsd:integer	Types.INTEGER	xsd:dateTimeStamp	Types.TIMESTAMP
xsd:int	Types.INTEGER	xsd:date	Types.DATE
xsd:short	Types.SMALLINT	xsd:time	Types.TIME
xsd:byte	Types.TINYINT	xsd:gYearMonth	Types.VARCHAR
xsd:nonNegativeInteger	Types.BIGINT	xsd:gMonthDay	Types.VARCHAR
xsd:nonPositiveInteger	Types.BIGINT	xsd:gYear	Types.VARCHAR
xsd:negativeInteger	Types.BIGINT	xsd:gMonth	Types.VARCHAR
xsd:positiveInteger	Types.BIGINT	xsd:gDay	Types.VARCHAR
xsd:unsignedLong	Types.BIGINT
xsd:unsignedInt	Types.BIGINT
xsd:unsignedShort	Types.INTEGER

• Likewise, SqlTypeToXmlType defines type conversion SQL --> XSD in the following.

SQL	XSD	SQL	XSD
Types.NUMERIC	xsd:decimal	Types.NVARCHAR	xsd:string
Types.DECIMAL	xsd:decimal	Types.LONGVARCHAR	xsd:string
Types.BIGINT	xsd:long	Types.LONGNVARCHAR	xsd:string
Types.INTEGER	xsd:integer	Types.DATE	xsd:date
Types.SMALLINT	xsd:short	Types.TIME	xsd:time
Types.TINYINT	xsd:byte	Types.TIMESTAMP	xsd:dateTime
Types.REAL	xsd:float	Types.BOOLEAN	xsd:boolean
Types.FLOAT	xsd:float	Types.BIT	xsd:boolean
Types.DOUBLE	xsd:double	Types.OTHER	xsd:string
Types.CHAR	xsd:string
Types.VARCHAR	xsd:string
Types.NCHAR	xsd:string

Bug Fixes

[#11] Fix the incorrect value representation when the mapping term is specified as rr:IRI.
[#12] The API should distinguish between literal-value and object-value (IRI-value).

1.6

Release Notes:

• Programmatic Configuration
  Users can make configuration settings coded in Java program instead of using external application.cfg.xml file. It is useful to embed the settings entirely into the program without enclosing any revealing text. You can find the manual to use this in our wiki page
• Support SPARQL LIMIT and OFFSET
  More support on SPARQL syntax. Users can use these expressions to modify the query result based on the returned size (LIMIT) and/or the starting number of rows (OFFSET).
• Improved TERMAL/XML
  This is the native mapping language for Semantika, written in XML. The coding structure has been improved to follow better R2RML specification. This update makes both TERMAL/XML and R2RML format have a better compatibility in their semantic.

Bug Fixes:

[#7] Fix the incorrect datatype translation from SQL INT or INTEGER to XML Schema xsd:int
[#8] Add syntactic sugar writing for datatype xsd:string. The materializer may produce the text without specifying its datatype.
[#9] Fix the incorrect type assignment when users specified term type as Literal (i.e., rr:termType="rr:Literal". The default assignment should be as xsd:string.
[#10] Fix NullPointerException when the query result returns a valid URI/URL object

Known Limitations:

• The system does not support referencing object map in R2RML document, i.e., using properties such as rr:parentTriplesMap, rr:joinCondition, rr:child and rr:parent.
• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• The SQL mapping parser will produce an exception when handling a self-join expression.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL
  • BOUND, LANG, LANGMATCHES, REGEX
  • LIMIT, OFFSET
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.5

Release Notes:

Support R2RML Mappings
Semantika now supports writing RDB/RDF mappings using R2RML specification. Most of the essential properties are recognized well by the system, such as rr:logicalTable, rr:subjectMap, rr:predicateObjectMap, rr:predicate, rr:objectMap, etc.

Known Limitations:

• The system does not support referencing object map in R2RML, i.e., using properties such as rr:parentTriplesMap, rr:joinCondition, rr:child and rr:parent.
• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• The SQL mapping parser will produce an exception when handling a self-join expression.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • LIMIT, OFFSET
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.4

Release Notes:

Support on Complex OPTIONAL
Semantika now supports SQL generation from more complex SPARQL OPTIONAL expressions, such as:

• Multiline OPTIONAL (i.e., nested JOIN within OPTIONAL). For instance:

 SELECT ?x ?propA ?propB ?propC
 WHERE {
   ?x :hasPropertyA ?propA
   OPTIONAL {
     ?x :hasPropertyB ?propB;
        :hasPropertyY ?y .  
     ?y :hasPropertyC ?propC    
   }
 }

• Nested OPTIONAL. For instance:

 SELECT ?x ?propA ?propB ?propC ?propD ?propE
 WHERE {
   ?x :hasPropertyA ?propA
   OPTIONAL {
     ?x :hasPropertyB ?propB;
        :hasPropertyY ?y .  
     ?y :hasPropertyC ?propC
     OPTIONAL { ?y :hasPropertyD ?propD }
     OPTIONAL { ?y :hasPropertyE ?propE }  
   }
 }

Bug Fixes:

[#4]: Column not found when writing using backticks (or quotes) in SQL mapping.
[#5]: Semantika throws exception when using divide operation in SQL select item.
[#6]: Uncaught exception when the input URI template is null from database

Known Limitations:

• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• The SQL mapping parser will produce an exception when handling a self-join expression.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.3

Release Notes:

• Connection Pool
  Semantika can be configured to use a connection pool as its connection provider. The implementation uses c3p0 library that handles transparent connection pooling and it is suitable for high-volume application.
• JDBC Transaction Settings
  In addition to the connection pool, the configuration file has more parameters to adjust the transaction behavior in JDBC connection. Users are able to set QUERY_TIMEOUT, FETCH_SIZE and MAX_FETCH_ROW settings.
• Multiple Mapping Input
  The configuration file is able to handle multiple mapping files as input. This allows users to work on separate mappings and load them collectively during the runtime.
• User's Query
  No limit on writing complex SQL string for the source data mapping. Semantika will not reject such query and will take the input literally. This feature is very beneficial for RDB2RDF users. However, due to the fact Semantika will not process this input, it can't be optimized and can affect performance. Therefore, QueryAnswer users is recommended to use this feature moderately.
• Support rr:subject and rr:object for RDB2RDF
  The mapping language supports contant-valued term map in subject map and predicate-object map.

Library Update

• Update OpenRDF Sesame library from version 2.7.8 --> 2.7.11
• Update OWLAPI library from version 3.4.2 --> 3.4.8
• Update JSQLParser library from version 0.8.0 --> 0.8.9

Known Limitations:

• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• The SQL mapping parser will produce an exception when handling a self-join expression.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL*)
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Multilined OPTIONAL and Nested OPTIONAL are not supported yet.
**) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.2

Release Notes:

• Support rr:datatype for RDB2RDF
  The mapping language supports datatype-able term map to generate typed literals. Usually the datatype of literals are automatically determined based on the SQL datatype of the underlying logical table column. However, with the new syntax rr:datatype users can explicitly override the type and producing a datatype-override RDF literal. Currently, this feature works well for materialisation purpose only.
• More SPARQL Support
  Users can formulate filter expression using the built-in functions: BOUND, REGEX and LANG.

Known Limitations:

• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL*)
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Multilined OPTIONAL and Nested OPTIONAL are not supported yet.
**) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.1.5

Release Notes:

This is an intermediate release for the upcoming 1.2. It has many significant changes and bug fixes at the core code.

• Improved Query Cache
  The query caching algorithm has been improved by using Most Recently Used (MRU) algorithm to maintain a bounded in-memory size that will prevent caching size explosion. The least recently used query will be the first available for removal from the cache.
• SQL Decoupling
  The decoupling makes the code easier to read and to maintain. It gives a different perspective between input query object in SPARQL and output query object in SQL.
• Database Connection Provider
  The API has a clear abstraction for the database connection provider which allows different kind of connections (e.g., single, pooled connections) to be implemented easily.

Bug Fix:

[#1]: Bug in generating SQL in successive runs
[#2]: ListResultHandler fails to recognize xsd:anyURI type
[#3]: Critical error when generating multiple SQL JOIN table expressions.

Known Limitations:

• We encourage to use JOIN keyword when expressing join tables and avoid using alias name for tables when possible.
• Currently the system supports only MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL*)
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Nested OPTIONAL is not supported yet.
**) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive but it covers the usual operators in practice. More additions may be possible in the future.

1.1

Release Notes:

• Advanced QueryReducer
  The QueryEngine is now equipped with QueryReducer for optimizing SQL string by eliminating redundant joins and sub-queries, if possible. The module will maintain the correctness of the original query while trimming the excess. The end result is a compact SQL that is faster to run.
• SPARQL OPTIONAL
  Support using OPTIONAL keyword in query. However, complex query expression using nested optional is not supported yet.

Known Limitations:

• Unexpected behaviour when adding alias name in simple join expressions in mappings. It is advisable to use JOIN keyword when expressing join tables and avoid using alias names when possible.
• Only support MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL*)
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY**)
  • ORDER BY**)
  • DESCRIBE**)
  • ASK**)

*) Nested OPTIONAL is not supported yet.
**) Elements in strikethrough won't be supported in the entire development.

Note: The list is not intended to be exhaustive, but it covers the usual operators in practice. Additions may be possible

1.0

Release Notes:

• SPARQL Query Engine
  Support query answer using SPARQL 1.1 specification. The engine is able to translate the query into SQL language according to the underlying database system. The engine is still in early development and we'd like to hear you feedback.
• Advanced Query Result
  Application developer can play around the QueryResult programmatically. Moreover, the result can be reconstruct into any object by writing your own custom QueryResultHandler.
• Result Paging
  We understand the need to organize huge query to save resources. The "extended" query engine can serve custom paging that will retrieve results part-by-part.
• NULL Materialization
  Fix issue when exporting NULL value from the database. The resolution was to exclude tuples that have NULL values (i.e., they are not being materialized into RDF data).

Known Limitations:

• Only support MySQL, PostgreSQL and H2.
• SPARQL 1.1 List of Support:
  • SELECT
  • DISTINCT
  • EQ, NE, GT, GTE, LT, LTE
  • AND, OR, NOT
  • OPTIONAL
  • BOUND, LANG, LANGMATCHES, REGEX
  • CONSTRUCT
  • GROUP BY
  • ORDER BY
  • DESCRIBE
  • ASK

Note:

1. Elements in strikethrough won't be supported in the entire development.
2. The list is not intended to be exhaustive, but it covers the most majority in the application. Additions may be possible