Options datatype and language are ignored by Literal classes

[galgonek]

It seems that Virtuoso ignores datatype and language options in create Literal class statements.

If I create the table —

create table "TEST"."TEST"."EXAMPLE"(
  id integer primary key,
  name VARCHAR(100)
);

insert soft "TEST"."TEST"."EXAMPLE" values (1, 'Virtuoso');

— and define the mapping —

sparql
prefix virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>
create IRI class <class:id> "http://example.com/entity/%d" (in id integer) .
create Literal class <class:lang> "%s" (in name varchar) option (lang "en") .
create Literal class <class:type> "%s" (in name varchar) option (datatype <http://example.com/mystring> ) .
create quad storage virtrdf:Example from "TEST"."TEST"."EXAMPLE" as tbl {
  create <http://temp/example> as graph <http://example.com/> {
    <class:id> (tbl."id")
      <http://example.com/test1> <class:lang> (tbl."name") ;
      <http://example.com/test2> <class:type> (tbl."name") .
  }
};

— then the SPARQL query —

sparql define input:storage virtrdf:Example
select ?P ?O (datatype(?O) as ?datatype) (lang(?O) as ?lang) where { ?S ?P ?O };

--- returns the result ---	P LONG VARCHAR	O LONG VARCHAR	datatype LONG VARCHAR	lang LONG VARCHAR
http://example.com/test1	Virtuoso	http://www.w3.org/2001/XMLSchema#string	BLOB 0 chars
http://example.com/test2	Virtuoso	http://www.w3.org/2001/XMLSchema#string	BLOB 0 chars

However, the result ---	P LONG VARCHAR	O LONG VARCHAR	datatype LONG VARCHAR	lang LONG VARCHAR
http://example.com/test1	Virtuoso	http://www.w3.org/1999/02/22-rdf-syntax-ns#langString	en
http://example.com/test2	Virtuoso	http://example.com/mystring

--- should be returned.

[TallTed]

@galgonek -- Please confirm the exact version of Virtuoso in use for this test, with the first stanza of output from the command-line virtuoso-t -? or virtuoso-odbc -? (or otherwise adjusted to match the Virtuoso executable name in your environment).

@pvk @HughWilliams @imitko @IvanMikhailov @openlink -- Please look into this issue with User-defined Custom Data Types.

[galgonek]

@TallTed -- I have tested the last stable version —

Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.6.3233-pthreads as of Jan 21 2022 (000000)
Compiled for Linux (x86_64-pc-linux-gnu)

— and the last devel version —

Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.7-dev.3233-pthreads as of Jan 21 2022 (000000)
Compiled for Linux (x86_64-pc-linux-gnu)

[TallTed]

@galgonek -- It appears you have built from a packaged download of source from GitHub, which leaves out a key snippet, which you can get with a proper clone -- which changes the (000000) seen in the strings above, to a GitHead value (such as (1963b2bb52), which I got from the current DBpedia backend via SPARQL query). You may be able to manually glean the "latest commit ID" from the two source trees you built from, which will help us be sure we're looking at the same things.

[galgonek]

@TallTed

Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.6.3233-pthreads as of Jan 21 2022 (64663f91c)
Compiled for Linux (x86_64-pc-linux-gnu)

— and —

Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.7-dev.3233-pthreads as of Jan 21 2022 (5f9a2ffdf)
Compiled for Linux (x86_64-pc-linux-gnu)

[HughWilliams]

I have been able to recreate this problem and reported to development to look into and fix ...

[jmkeil]

Might #428 and #946 be related to this?

[TallTed]

Might #428 and #946 be related to this?

@jmkeil -- Good question. I've noted this possibility internally, where we're tracking #1003 as bug#19162, and #428 as bug#17168. (#946 has no internal bug# at this time.)