Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

Changing ttlpv.sql to use insert soft (and also making sure to use the
stored id) appears to fix the problem I am encountering.

I prepared a modified ttlpv.sql (attached) and reinstalled Virtuoso as
follows:

cd /home/virtuoso/test
killall virtuoso-t
rm -rf vos
cp ttlpv.sql ./virtuoso-opensource/libsrc/Wi
cd virtuoso-opensource/
make
make install prefix=/home/virtuoso/test/vos
cd ..
cp generate.py vos/share/virtuoso/vad
( cd vos/share/virtuoso/vad ; python2.7 ./generate.py )
./test.sh

With this change everything worked.

I expect that when using insert soft that rdf_rl_lang_id could be somewhat
shortened but I wanted to make the minimal change.


peter


ttlpv.sql
Description: application/sql
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

Aah.  It's likely then that something in MacOS doesn't switch between threads
within ttlpv.sql.

It is also possible that there is a similar issue in ttlpv.sql having to do
with type ids (rdf_rl_type_id).  That code is very similar to the code where I
found the bug.

peter


On 12/19/18 11:05 AM, Hugh Williams wrote:
> Hi Peter,
> 
> My original testing was on Darwin (macOS), I have switched to CentOS 7 and
> have been able to recreate the issue on first run:
> 
> [hwilliams@localhost database]$ sh test.sh 
> Wed 19 Dec 15:43:33 GMT 2018: 3/ Start up Virtuoso with an empty database
> OpenLink Virtuoso Interactive SQL (Virtuoso)
> Version 07.20.3230 as of Oct 18 2018
> Type HELP; for help and EXIT; to exit.
> Connected to OpenLink Virtuoso
> Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
> Wed 19 Dec 15:43:39 GMT 2018: 4/ Load the dump files into Virtuoso
> test.sh: line 35: warning: here-document at line 18 delimited by end-of-file
> (wanted `EOF')
> ll_file                                                                      
>     ll_state    ll_error
> ___
> 
> /home/hwilliams/virtuoso/vos72/virtuoso-opensource/wikidata/test00.ttl        
>    2           23000 TURTLE RDF loader, line 507: SR197: Non unique primary
> key on DB.DBA.RDF_LANGUAGE.
> [hwilliams@localhost database]$ 
> 
> and sometimes does not occur ...
> 
> I shall report to development to look into and also provide them with the
> “ttlpv.sql” script with your proposed fix ...
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers
> Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
> 
>> On 19 Dec 2018, at 13:51, Peter F. Patel-Schneider > <mailto:pfpschnei...@gmail.com>> wrote:
>>
>> That's not my experience on several machines.  I've experienced this bug on
>> two servers, one running CentOS release 6.9 (Final) and one running Ubuntu
>> 16.04.5 LTS.  The bug depends at least on loading in parallel *and*
>> encountering new language tags.  Loading the files a second time will almost
>> certainly result in no errors as the language tags will already have been
>> encountered and added in the previous partially completed run.
>>
>>
>> To check things out a bit further I tested on a new machine.  I did a fresh
>> download and install of Virtuoso Open Source (Version 07.20.3230 as of Dec
>> 19 2018) on my laptop (a four-core, eight-thread machine running Fedora 29
>> with kernel 4.19.8-300.fc29.x86_64).
>>
>> I downloaded, compiled, and installed Virtuoso as follows:
>>
>> cd /home/virtuoso/test
>> git clone git://github.com/openlink/virtuoso-opensource.git
>> cd virtuoso-opensource
>> ./autogen.sh
>> ./configure
>> make
>> make install prefix=/home/virtuoso/test/vos
>> cd ..
>>
>> I put my generation code in the directory .../share/virtuoso/vad/ and
>> creaated the download files there so that I did not have to change
>> virtuoso.ini at all.   I then ran a slightly modified version of the test
>> script (attached).
>>
>> cp generate.py vos/share/virtuoso/vad
>> ( cd vos/share/virtuoso/vad ; python2.7 ./generate.py )
>> ./test.sh
>>
>> The test script produced
>>
>> #!/bin/bash -v
>> # Installation directories for Virtuoso open source
>> vrun=/home/virtuoso/test/vos
>> vbin=${vrun}/bin
>> vdb=${vrun}/var/lib/virtuoso/db
>>
>> # Start up virtuoso as a daemon, waiting for initialization
>> ( cd ${vdb} ; ${vbin}/virtuoso-t +wait )
>>
>> ${vbin}/isql  dba dba PROMPT=OFF <> ld_dir ('/home/virtuoso/test/vos/share/virtuoso/vad', 'test*.ttl',
>> 'http://test.nuance.com');
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &
>> rdf_loader_run() &

Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

That's not my experience on several machines.  I've experienced this bug on
two servers, one running CentOS release 6.9 (Final) and one running Ubuntu
16.04.5 LTS.  The bug depends at least on loading in parallel *and*
encountering new language tags.  Loading the files a second time will almost
certainly result in no errors as the language tags will already have been
encountered and added in the previous partially completed run.


To check things out a bit further I tested on a new machine.  I did a fresh
download and install of Virtuoso Open Source (Version 07.20.3230 as of Dec
19 2018) on my laptop (a four-core, eight-thread machine running Fedora 29
with kernel 4.19.8-300.fc29.x86_64).

I downloaded, compiled, and installed Virtuoso as follows:

cd /home/virtuoso/test
git clone git://github.com/openlink/virtuoso-opensource.git
cd virtuoso-opensource
./autogen.sh
./configure
make
make install prefix=/home/virtuoso/test/vos
cd ..

I put my generation code in the directory .../share/virtuoso/vad/ and
creaated the download files there so that I did not have to change
virtuoso.ini at all.   I then ran a slightly modified version of the test
script (attached).

cp generate.py vos/share/virtuoso/vad
( cd vos/share/virtuoso/vad ; python2.7 ./generate.py )
./test.sh

The test script produced

#!/bin/bash -v
# Installation directories for Virtuoso open source
vrun=/home/virtuoso/test/vos
vbin=${vrun}/bin
vdb=${vrun}/var/lib/virtuoso/db

# Start up virtuoso as a daemon, waiting for initialization
( cd ${vdb} ; ${vbin}/virtuoso-t +wait )

${vbin}/isql  dba dba PROMPT=OFF  WHERE {?s ?p ?o};
exit;
EOF
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver

Done. -- 1 msec.
OpenLink Virtuoso Interactive SQL (Virtuoso)
OpenLink Virtuoso Interactive SQL (Virtuoso)
OpenLink Virtuoso Interactive SQL (Virtuoso)
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Version 07.20.3230 as of Dec 19 2018
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
Type HELP; for help and EXIT; to exit.
Type HELP; for help and EXIT; to exit.
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
OpenLink Virtuoso Interactive SQL (Virtuoso)
Version 07.20.3230 as of Dec 19 2018
Type HELP; for help and EXIT; to exit.
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver

Done. -- 0 msec.

Done. -- 0 msec.




Done. -- 42 msec.
Done. -- 42 msec.
Done. -- 43 msec.
Done. -- 42 msec.

Done. -- 41 msec.

Done. -- 41 msec.

Done. -- 58 msec.

Done. -- 265 msec.

Done. -- 68 msec.
ll_file
ll_graph
ll_statell_started   ll_done  ll_host
ll_work_time  ll_error
VARCHAR NOT NULL
VARCHAR
INTEGER TIMESTAMPTIMESTAMPINTEGER
INTEGER VARCHAR
___

/home/virtuoso/test/vos/share/virtuoso/vad/test00.ttl
http://test.nuance.com
2   2018.12.19 8:35.33 146481000  2018.12.19 8:35.33 148859000
 0   NULL23000 TURTLE RDF loader, line 17: SR197: Non unique
primary key on DB.DBA.RDF_LANGUAGE.
/home/virtuoso/test/v

Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

I created some synthetic data that tickles the bug reliably on my machine with
a standard virtuoso.ini (just adding the directory for the files to the
allowed list).  I'm attaching the generator program for the files and a
loading script.

peter


On 12/18/18 9:46 AM, Peter F. Patel-Schneider wrote:
> I did a bit of digging and it sure looks as if there is a race condition in
> rdf_rl_lang_id in ttlpv.sql.   This code appears to check to see if the
> language tag is already in DB.DBA.RDF_LANGUAGE and adds it if not.  But
> another thread could do the same insert between the check and the insert, as
> far as I can tell.
> 
> It looks to me as if the right solution is to do a soft insert and a
> subsequent query instead of a hard insert.
> 
> However, I don't understand how locking works in SQL so there may be something
> that prevents another thread from interfering.
> 
> peter
> 
> 
> On 12/18/18 8:55 AM, Peter F. Patel-Schneider wrote:
>> I'm loading the Turtle Wikidata RDF complete dump, split into pieces and
>> loaded with 10 active readers.   About half the time the load fails with one
>> or more of these errors.  The errors are always near the beginning of the
>> load---in the first group of 10 files to be loaded and near the beginning of
>> the files (generally in the first couple of hundred lines in a file of size
>> well over 1 GB).  No errors occur for any files beyond the first ten.
>>
>> I could provide the files, but they total to about 340GB.
>>
>> It sure looks as if there is some sort of bug when loading RDF 
>> language-tagged
>> strings, where a race condition means that two threads are trying to load the
>> same language tag into DB.DBA.RDF_LANGUAGE.  This would explain why the
>> problem occurs only at the beginning of the load, when the language tags are
>> being added to DB.DBA.RDF_LANGUAGE, and not later.  It would also explain why
>> the errors are different between different runs.  (The only other explanation
>> would be hardware errors, but this doesn't seem to be viable.)
>>
>> It seems to me that a quick patch for this problem would be to change the
>> insert into a soft insert, but I don't know where to make this change in the 
>> code.
>>
>> peter
>>
>>
>>
>>
>> On 12/11/18 7:11 PM, Hugh Williams wrote:
>>> Hi Peter,
>>>
>>> The triple value do indeed appear to be valid, but the problem could be
>>> somewhere else in the dataset file and not necessarily on the reported line 
>>> or
>>> line before it.
>>>
>>> Is it a public dataset you are loading and if so can you provide a copy for
>>> local testing ?
>>>
>>> Best Regards
>>> Hugh Williams
>>> Professional Services
>>> OpenLink Software
>>> Home Page: http://www.openlinksw.com
>>> Community Support: https://community.openlinksw.com
>>> Weblogs (Blogs):
>>> Company Blog: https://medium.com/openlink-software-blog
>>> Virtuoso Blog: https://medium.com/virtuoso-blog
>>> Data Access Drivers
>>> Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>> Twitter  -- http://twitter.com/OpenLink
>>> Google+  -- http://plus.google.com/100570109519069333827/
>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>> Universal Data Access, Integration, and Management Technology Providers
>>>
>>>
>>>
>>>
>>>> On 11 Dec 2018, at 17:45, Peter F. Patel-Schneider >>> <mailto:pfpschnei...@gmail.com>> wrote:
>>>>
>>>> I'm loading a bunch of Turtle files and I'm getting the error
>>>>
>>>> 2300 TURTLE RDF loader, line 1012: SR197: Non unique primary key on
>>>> DB.DBA.RDF_LANGUAGE
>>>>
>>>> The line in question looks fine:
>>>>
>>>>   "Wikimedia template"@ki,
>>>>
>>>> The line before it may indicate the issue
>>>>
>>>>    "Wikimedia template"@kg,
>>>>
>>>> Nonetheless this should be valid RDF so there appears to be a bug in 
>>>> Virtuoso
>>>> here.
>>>>
>>>> Is there any workaround?
>>>>
>>>>
>>>> This is in Virtuoso 07.20.3230.
>>>>
>>>> peter
>>>>
>>>>
>>>> ___
>>>> Virtuoso-users mailing l

Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

I did a bit of digging and it sure looks as if there is a race condition in
rdf_rl_lang_id in ttlpv.sql.   This code appears to check to see if the
language tag is already in DB.DBA.RDF_LANGUAGE and adds it if not.  But
another thread could do the same insert between the check and the insert, as
far as I can tell.

It looks to me as if the right solution is to do a soft insert and a
subsequent query instead of a hard insert.

However, I don't understand how locking works in SQL so there may be something
that prevents another thread from interfering.

peter


On 12/18/18 8:55 AM, Peter F. Patel-Schneider wrote:
> I'm loading the Turtle Wikidata RDF complete dump, split into pieces and
> loaded with 10 active readers.   About half the time the load fails with one
> or more of these errors.  The errors are always near the beginning of the
> load---in the first group of 10 files to be loaded and near the beginning of
> the files (generally in the first couple of hundred lines in a file of size
> well over 1 GB).  No errors occur for any files beyond the first ten.
> 
> I could provide the files, but they total to about 340GB.
> 
> It sure looks as if there is some sort of bug when loading RDF language-tagged
> strings, where a race condition means that two threads are trying to load the
> same language tag into DB.DBA.RDF_LANGUAGE.  This would explain why the
> problem occurs only at the beginning of the load, when the language tags are
> being added to DB.DBA.RDF_LANGUAGE, and not later.  It would also explain why
> the errors are different between different runs.  (The only other explanation
> would be hardware errors, but this doesn't seem to be viable.)
> 
> It seems to me that a quick patch for this problem would be to change the
> insert into a soft insert, but I don't know where to make this change in the 
> code.
> 
> peter
> 
> 
> 
> 
> On 12/11/18 7:11 PM, Hugh Williams wrote:
>> Hi Peter,
>>
>> The triple value do indeed appear to be valid, but the problem could be
>> somewhere else in the dataset file and not necessarily on the reported line 
>> or
>> line before it.
>>
>> Is it a public dataset you are loading and if so can you provide a copy for
>> local testing ?
>>
>> Best Regards
>> Hugh Williams
>> Professional Services
>> OpenLink Software
>> Home Page: http://www.openlinksw.com
>> Community Support: https://community.openlinksw.com
>> Weblogs (Blogs):
>> Company Blog: https://medium.com/openlink-software-blog
>> Virtuoso Blog: https://medium.com/virtuoso-blog
>> Data Access Drivers
>> Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>> Twitter  -- http://twitter.com/OpenLink
>> Google+  -- http://plus.google.com/100570109519069333827/
>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>> Universal Data Access, Integration, and Management Technology Providers
>>
>>
>>
>>
>>> On 11 Dec 2018, at 17:45, Peter F. Patel-Schneider >> <mailto:pfpschnei...@gmail.com>> wrote:
>>>
>>> I'm loading a bunch of Turtle files and I'm getting the error
>>>
>>> 2300 TURTLE RDF loader, line 1012: SR197: Non unique primary key on
>>> DB.DBA.RDF_LANGUAGE
>>>
>>> The line in question looks fine:
>>>
>>>   "Wikimedia template"@ki,
>>>
>>> The line before it may indicate the issue
>>>
>>>    "Wikimedia template"@kg,
>>>
>>> Nonetheless this should be valid RDF so there appears to be a bug in 
>>> Virtuoso
>>> here.
>>>
>>> Is there any workaround?
>>>
>>>
>>> This is in Virtuoso 07.20.3230.
>>>
>>> peter
>>>
>>>
>>> ___
>>> Virtuoso-users mailing list
>>> Virtuoso-users@lists.sourceforge.net
>>> <mailto:Virtuoso-users@lists.sourceforge.net>
>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

I'm loading the Turtle Wikidata RDF complete dump, split into pieces and
loaded with 10 active readers.   About half the time the load fails with one
or more of these errors.  The errors are always near the beginning of the
load---in the first group of 10 files to be loaded and near the beginning of
the files (generally in the first couple of hundred lines in a file of size
well over 1 GB).  No errors occur for any files beyond the first ten.

I could provide the files, but they total to about 340GB.

It sure looks as if there is some sort of bug when loading RDF language-tagged
strings, where a race condition means that two threads are trying to load the
same language tag into DB.DBA.RDF_LANGUAGE.  This would explain why the
problem occurs only at the beginning of the load, when the language tags are
being added to DB.DBA.RDF_LANGUAGE, and not later.  It would also explain why
the errors are different between different runs.  (The only other explanation
would be hardware errors, but this doesn't seem to be viable.)

It seems to me that a quick patch for this problem would be to change the
insert into a soft insert, but I don't know where to make this change in the 
code.

peter




On 12/11/18 7:11 PM, Hugh Williams wrote:
> Hi Peter,
> 
> The triple value do indeed appear to be valid, but the problem could be
> somewhere else in the dataset file and not necessarily on the reported line or
> line before it.
> 
> Is it a public dataset you are loading and if so can you provide a copy for
> local testing ?
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software
> Home Page: http://www.openlinksw.com
> Community Support: https://community.openlinksw.com
> Weblogs (Blogs):
> Company Blog: https://medium.com/openlink-software-blog
> Virtuoso Blog: https://medium.com/virtuoso-blog
> Data Access Drivers
> Blog: https://medium.com/openlink-odbc-jdbc-ado-net-data-access-drivers
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
> 
>> On 11 Dec 2018, at 17:45, Peter F. Patel-Schneider > <mailto:pfpschnei...@gmail.com>> wrote:
>>
>> I'm loading a bunch of Turtle files and I'm getting the error
>>
>> 2300 TURTLE RDF loader, line 1012: SR197: Non unique primary key on
>> DB.DBA.RDF_LANGUAGE
>>
>> The line in question looks fine:
>>
>>   "Wikimedia template"@ki,
>>
>> The line before it may indicate the issue
>>
>>    "Wikimedia template"@kg,
>>
>> Nonetheless this should be valid RDF so there appears to be a bug in Virtuoso
>> here.
>>
>> Is there any workaround?
>>
>>
>> This is in Virtuoso 07.20.3230.
>>
>> peter
>>
>>
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> <mailto:Virtuoso-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] strange error when bulk-loading Turtle files

[Peter F. Patel-Schneider]

I'm loading a bunch of Turtle files and I'm getting the error

2300 TURTLE RDF loader, line 1012: SR197: Non unique primary key on
DB.DBA.RDF_LANGUAGE

The line in question looks fine:

   "Wikimedia template"@ki,

The line before it may indicate the issue

"Wikimedia template"@kg,

Nonetheless this should be valid RDF so there appears to be a bug in Virtuoso
here.

Is there any workaround?


This is in Virtuoso 07.20.3230.

peter


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] context-sensitive syntax for transitive paths in Virtuoso open source

[Peter F. Patel-Schneider]

I'm getting a strange syntax error from Virtuoso Open Source related to
transitive paths.

Connected to OpenLink Virtuoso
Driver: 07.20.3230 OpenLink Virtuoso ODBC Driver
SQL> SPARQL PREFIX wdt:  SELECT ( COUNT
(DISTINCT ?s) AS ?subclasses ) WHERE { GRAPH  { ?s
wdt:P279/wdt:P279* ?t . } } ;

*** Error 37000: [Virtuoso Driver][Virtuoso Server]TR...: Query contains a
transitive derived table but neither end of it is bound by equality to other
columns or parameters
at line 1 of Top-Level:
SPARQL PREFIX wdt:  SELECT ( COUNT
(DISTINCT ?s) AS ?subclasses ) WHERE { GRAPH  { ?s
wdt:P279/wdt:P279* ?t . } }

SQL> SPARQL PREFIX wdt:  SELECT ( COUNT
(DISTINCT *) AS ?subclasses ) WHERE { GRAPH  { ?s
wdt:P279/wdt:P279* ?t . } } ;
Result is 38781929 in 616 seconds

SQL> SPARQL PREFIX wdt:  SELECT ( COUNT
(DISTINCT ?s) AS ?subclasses ) WHERE { ?s wdt:P279/wdt:P279* ?t . } ;
Result is 1488308 in 87 seconds

SQL> SPARQL PREFIX wdt:  SELECT ( COUNT
(DISTINCT *) AS ?subclasses ) WHERE { ?s wdt:P279/wdt:P279* ?t . } ;
Result is 38781929 in 614 seconds

Why is the first query not working when the others do?

peter


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] GeoSPARQL

[Peter F. Patel-Schneider]

I was hoping that non-terrestrial coordinates would be allowed with this
change, but it appears not.

peter


On 11/15/18 1:34 AM, Pasquale Di Donato wrote:
> Hi all,
> 
> is there a built version with the new GeoSPARQL support enabled?
> Or am I obliged to compile?
> 
> thanks
> Pasquale
> 
> 
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] memory consumption when loading large triple files

[Peter F. Patel-Schneider]

I'm loading a large Turtle file with almost 7 billion triples in it.

As the file is loaded virtuoso takes up more and more memory, much more than
it should.  I had set it for 24GB of memory available on a machine with 32GB
of memory but eventually it took up all the available virtual memory and
crashed.  Near the end it was using around 97% of main memory and kswapd0 was
consuming about 25% of a processing unit.

Is it expected that virtuoso needs this extra memory when loading a large
Turtle file or is this a bug of some sort?

peter


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Error SR078: The result set is too long, must limit result for at most 2097151 rows

[Peter F. Patel-Schneider]

Thanks.  I'm now using pyodbc to connect to the ODBC interface, which works
quite well.

peter


On 9/6/18 5:49 AM, Hugh Williams wrote:
> Hi Peter,
> 
> You can get around this by using LIMIT / OFFSET in the query or by using one 
> of the SQL interfaces ie ODBC / JDBC / ADO.Net etc as was indicated in the 
> git issue (https://github.com/openlink/virtuoso-opensource/issues/700) and 
> even using our Jena/Sesame Provider which use JDBC under the covers for 
> connecting to Virtuoso ...
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc.  //  http://www.openlinksw.com/
> Weblog   -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
>> On 6 Sep 2018, at 09:30, Peter F. Patel-Schneider  
>> wrote:
>>
>> I had already bumped into the limit that you found.
>>
>> This is a second limit, also mentioned in that thread.  This limit is 
>> 2^(24-3)
>> for modern CPUs, as mentioned by iv-an-ru.  It is this limit that I'm bumping
>> into.  Unfortunately, this limit appears to be something that can't be
>> modified by simply changing a constant.
>>
>> I do not know just what this limit constrains.  Can I get around it by using
>> one of the other interfaces to Virtuoso?  Can I get around it by using LIMIT
>> and OFFSET?
>>
>> peter
>>
>>
>> On 09/05/2018 08:19 PM, Daniel Hernandez wrote:
>>> Peter,
>>>
>>> I have faced the same problem. It can be partially solved by modifying
>>> the code of Virtuoso to remove the hardcoded limit. It implies recompiling
>>> Virtuoso. This issue is commented here:
>>>
>>> https://github.com/openlink/virtuoso-opensource/issues/700
>>>
>>> Daniel
>>>
>>>
>>>  On Wed, 05 Sep 2018 21:30:01 -0300 Peter F. Patel-Schneider 
>>>  wrote  
>>>> I'm trying to extract information from a large triple store and I'm 
>>>> running 
>>>> into Error SR078, which appears to be a hard limit on the number of rows 
>>>> in a 
>>>> result to 2^21 (for a 64 bit machine).  I'm using the http interface and 
>>>> I've 
>>>> already increased the maximum number of http results to well more than 
>>>> 2^21. 
>>>>
>>>> I was wondering if there was any way around this limit.  Does it affect 
>>>> all 
>>>> results or can I use another interface to Virtuoso to get around the 
>>>> problem? 
>>>> Can I use LIMIT and OFFSET to get around the problem (although that would 
>>>> be a 
>>>> rather costly way to get around it)? 
>>>>
>>>> peter 
>>>>
>>>> --
>>>>  
>>>> Check out the vibrant tech community on one of the world's most 
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
>>>> ___ 
>>>> Virtuoso-users mailing list 
>>>> Virtuoso-users@lists.sourceforge.net 
>>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users 
>>>>
>>>
>>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 


___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Error SR078: The result set is too long, must limit result for at most 2097151 rows

[Peter F. Patel-Schneider]

I had already bumped into the limit that you found.

This is a second limit, also mentioned in that thread.  This limit is 2^(24-3)
for modern CPUs, as mentioned by iv-an-ru.  It is this limit that I'm bumping
into.  Unfortunately, this limit appears to be something that can't be
modified by simply changing a constant.

I do not know just what this limit constrains.  Can I get around it by using
one of the other interfaces to Virtuoso?  Can I get around it by using LIMIT
and OFFSET?

peter


On 09/05/2018 08:19 PM, Daniel Hernandez wrote:
> Peter,
> 
> I have faced the same problem. It can be partially solved by modifying
> the code of Virtuoso to remove the hardcoded limit. It implies recompiling
> Virtuoso. This issue is commented here:
> 
> https://github.com/openlink/virtuoso-opensource/issues/700
> 
> Daniel
> 
> 
>  ---- On Wed, 05 Sep 2018 21:30:01 -0300 Peter F. Patel-Schneider 
>  wrote  
>  > I'm trying to extract information from a large triple store and I'm 
> running 
>  > into Error SR078, which appears to be a hard limit on the number of rows 
> in a 
>  > result to 2^21 (for a 64 bit machine).  I'm using the http interface and 
> I've 
>  > already increased the maximum number of http results to well more than 
> 2^21. 
>  >  
>  > I was wondering if there was any way around this limit.  Does it affect 
> all 
>  > results or can I use another interface to Virtuoso to get around the 
> problem? 
>  > Can I use LIMIT and OFFSET to get around the problem (although that would 
> be a 
>  > rather costly way to get around it)? 
>  >  
>  > peter 
>  >  
>  > 
> --
>  
>  > Check out the vibrant tech community on one of the world's most 
>  > engaging tech sites, Slashdot.org! http://sdm.link/slashdot 
>  > ___ 
>  > Virtuoso-users mailing list 
>  > Virtuoso-users@lists.sourceforge.net 
>  > https://lists.sourceforge.net/lists/listinfo/virtuoso-users 
>  > 
> 
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] Error SR078: The result set is too long, must limit result for at most 2097151 rows

[Peter F. Patel-Schneider]

I'm trying to extract information from a large triple store and I'm running
into Error SR078, which appears to be a hard limit on the number of rows in a
result to 2^21 (for a 64 bit machine).  I'm using the http interface and I've
already increased the maximum number of http results to well more than 2^21.

I was wondering if there was any way around this limit.  Does it affect all
results or can I use another interface to Virtuoso to get around the problem?
Can I use LIMIT and OFFSET to get around the problem (although that would be a
rather costly way to get around it)?

peter

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

Yes, that has the language tag side.  There is also the datatype side that
would be shown with Work/runtime.

peter


On 08/22/2018 10:08 AM, Kingsley Idehen wrote:
> On 8/22/18 12:01 PM, Peter F. Patel-Schneider wrote:
>> More or less, except that CSV output doesn't include language tags and 
>> doesn't
>> provide facilities for anything other than numeric and string literal values.
>> TSV format, on the other hand, does include language tags (shown explicitly 
>> in
>> an example) and datatypes (implied by wording in several places, particularly
>> "The SPARQL Results TSV Results Format does encode the details of RDF terms 
>> in
>> the results table by using the syntax that SPARQL [SPARQL11-QUERY] and Turtle
>> [TURTLE] use. An application receiving a TSV-encoded results set can split
>> each line into elements of the result row, and extract all the details it
>> wishes to process of the RDF terms by simple string processing, without a
>> complete XML or JSON parser required by the more complex SPARQL result 
>> formats.).
>>
>> So it's not a problem with the CSV output but instead with the TSV output.
>>
>> (I would be happy to have a variant of CSV that included language tags and
>> datatypes, but conforming to the requirements of TSV output would be better.)
>>
>> peter
> 
> Okay, so the following shows the problem, right?
> 
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3Flabel+lang%28%3Flabel%29+as+%3FlangTag%0D%0A+where+%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2F31_June%3E+rdfs%3Alabel+%3Flabel+%7D&format=text%2Ftab-separated-values&timeout=3
> 
> I am purposely using doc URIs as this helps the entire problem
> confirmation and resolution cycle.
> 
> 
> Kingsley
> 
> 
> 
>>
>>
>> On 08/22/2018 08:51 AM, Kingsley Idehen wrote:
>>> On 8/22/18 11:43 AM, Peter F. Patel-Schneider wrote:
>>>> Try
>>>>
>>>> curl http://dbpedia.org/sparql --get   --header "Accept:
>>>> text/tab-separated-values"  --data-urlencode query@- <>>> select * where { <http://dbpedia.org/resource/31_June> ?p ?o }
>>>> EOF
>>>>
>>>> Note that Work/runtime doesn't have a datatype and the labels don't have a
>>>> language tag even though 
>>>> https://www.w3.org/TR/sparql11-results-csv-tsv/#tsv
>>>> requires them.  As well, IRIs are enclosed in "" instead of <>.
>>>>
>>>> Then try the same query on the web interface at https://dbpedia.org/sparql.
>>>> There the datatypes and languages tags do show up.  However, there are some
>>>> langStrings without language tags there.
>>>>
>>>>
>>>> I'm also running into the same problem with a locally installed Virtuoso 
>>>> open
>>>> source 7.2.5.
>>>>
>>>> peter
>>>
>>> HTML-based SPARQL Results doc:
>>>
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3Flabel+lang%28%3Flabel%29+as+%3FlangTag%0D%0A+where+%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2F31_June%3E+rdfs%3Alabel+%3Flabel+%7D&format=text%2Fhtm&timeout=3
>>>
>>> CSV-based SPARQL Results doc:
>>>
>>> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3Flabel+lang%28%3Flabel%29+as+%3FlangTag%0D%0A+where+%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2F31_June%3E+rdfs%3Alabel+%3Flabel+%7D&format=text%2Fcsv&timeout=3
>>>
>>>
>>> I believe that demonstrates the problem re missing lang tags in the CSV
>>> output, right?
>>>
>>> -- 
>>> Regards,
>>>
>>> Kingsley Idehen   
>>> Founder & CEO 
>>> OpenLink Software   (Home Page: http://www.openlinksw.com)
>>>
>>> Weblogs (Blogs):
>>> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
>>> Blogspot Blog: http://kidehen.blogspot.com
>>> Medium Blog: https://medium.com/@kidehen
>>>
>>> Profile Pages:
>>> Pinterest: https://www.pinterest.com/kidehen/
>>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>>> Twitter: https://twitter.com/kidehen
>>> Google+: https://plus.google.com/+KingsleyIdehen/about
>>> LinkedIn: http://www.linkedin.com/in/kidehen
>>>
>>> Web Identities (WebID):
>>> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
>>> : 
>&

Re: [Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

That kind of solution is probably going to work for me for the short term, but
I don't know whether it will work in general.

peter


On 08/22/2018 08:58 AM, Hugh Williams wrote:
> Hi Peter,
> 
> How about something like:
> 
>   curl http://dbpedia.org/sparql --get  --data-urlencode "format=csv"  
> --data-urlencode 'query=select ?p ?o datatype(?o) as ?datatype lang(?o) as 
> ?lang where { <http://dbpedia.org/resource/31_June> ?p ?o }’
> 
> where output is presented in CSV format ?
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc.  //  http://www.openlinksw.com/
> Weblog   -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
> 
> 
>> On 22 Aug 2018, at 16:43, Peter F. Patel-Schneider  
>> wrote:
>>
>> Try
>>
>> curl http://dbpedia.org/sparql --get   --header "Accept:
>> text/tab-separated-values"  --data-urlencode query@- <> select * where { <http://dbpedia.org/resource/31_June> ?p ?o }
>> EOF
>>
>> Note that Work/runtime doesn't have a datatype and the labels don't have a
>> language tag even though https://www.w3.org/TR/sparql11-results-csv-tsv/#tsv
>> requires them.  As well, IRIs are enclosed in "" instead of <>.
>>
>> Then try the same query on the web interface at https://dbpedia.org/sparql.
>> There the datatypes and languages tags do show up.  However, there are some
>> langStrings without language tags there.
>>
>>
>> I'm also running into the same problem with a locally installed Virtuoso open
>> source 7.2.5.
>>
>> peter
>>
>>
>>
>>
>>
>>
>> On 08/22/2018 08:15 AM, Kingsley Idehen wrote:
>>> On 8/22/18 10:24 AM, Peter F. Patel-Schneider wrote:
>>>> I was hoping to be able to get the SPARQL TSV results format in
>>>> https://www.w3.org/TR/sparql11-results-csv-tsv/
>>>>
>>>> I can probably limp along with explicit language tags and datatypes but 
>>>> that's
>>>> a pain to process.
>>>>
>>>> peter
>>>
>>> Hi Peter,
>>>
>>> Please share a SPARQL Query Results doc URI that illustrates your
>>> problem. Then, if fixable, we can reply in kind with a URI that
>>> demonstrates the fix. 
>>>
>>>
>>>
>>>
>>> --
>>> Check out the vibrant tech community on one of the world's most
>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>
>>>
>>>
>>> ___
>>> Virtuoso-users mailing list
>>> Virtuoso-users@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
>>>
>>
>> --
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

More or less, except that CSV output doesn't include language tags and doesn't
provide facilities for anything other than numeric and string literal values.
TSV format, on the other hand, does include language tags (shown explicitly in
an example) and datatypes (implied by wording in several places, particularly
"The SPARQL Results TSV Results Format does encode the details of RDF terms in
the results table by using the syntax that SPARQL [SPARQL11-QUERY] and Turtle
[TURTLE] use. An application receiving a TSV-encoded results set can split
each line into elements of the result row, and extract all the details it
wishes to process of the RDF terms by simple string processing, without a
complete XML or JSON parser required by the more complex SPARQL result 
formats.).

So it's not a problem with the CSV output but instead with the TSV output.

(I would be happy to have a variant of CSV that included language tags and
datatypes, but conforming to the requirements of TSV output would be better.)

peter


On 08/22/2018 08:51 AM, Kingsley Idehen wrote:
> On 8/22/18 11:43 AM, Peter F. Patel-Schneider wrote:
>> Try
>>
>> curl http://dbpedia.org/sparql --get   --header "Accept:
>> text/tab-separated-values"  --data-urlencode query@- <> select * where { <http://dbpedia.org/resource/31_June> ?p ?o }
>> EOF
>>
>> Note that Work/runtime doesn't have a datatype and the labels don't have a
>> language tag even though https://www.w3.org/TR/sparql11-results-csv-tsv/#tsv
>> requires them.  As well, IRIs are enclosed in "" instead of <>.
>>
>> Then try the same query on the web interface at https://dbpedia.org/sparql.
>> There the datatypes and languages tags do show up.  However, there are some
>> langStrings without language tags there.
>>
>>
>> I'm also running into the same problem with a locally installed Virtuoso open
>> source 7.2.5.
>>
>> peter
> 
> 
> HTML-based SPARQL Results doc:
> 
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3Flabel+lang%28%3Flabel%29+as+%3FlangTag%0D%0A+where+%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2F31_June%3E+rdfs%3Alabel+%3Flabel+%7D&format=text%2Fhtm&timeout=3
> 
> CSV-based SPARQL Results doc:
> 
> http://dbpedia.org/sparql?default-graph-uri=http%3A%2F%2Fdbpedia.org&query=select+distinct+%3Flabel+lang%28%3Flabel%29+as+%3FlangTag%0D%0A+where+%7B+%3Chttp%3A%2F%2Fdbpedia.org%2Fresource%2F31_June%3E+rdfs%3Alabel+%3Flabel+%7D&format=text%2Fcsv&timeout=3
> 
> 
> I believe that demonstrates the problem re missing lang tags in the CSV
> output, right?
> 
> -- 
> Regards,
> 
> Kingsley Idehen 
> Founder & CEO 
> OpenLink Software   (Home Page: http://www.openlinksw.com)
> 
> Weblogs (Blogs):
> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
> Blogspot Blog: http://kidehen.blogspot.com
> Medium Blog: https://medium.com/@kidehen
> 
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
> 
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/public_home/kidehen/profile.ttl#i
> : 
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

Try

curl http://dbpedia.org/sparql --get   --header "Accept:
text/tab-separated-values"  --data-urlencode query@- <http://dbpedia.org/resource/31_June> ?p ?o }
EOF

Note that Work/runtime doesn't have a datatype and the labels don't have a
language tag even though https://www.w3.org/TR/sparql11-results-csv-tsv/#tsv
requires them.  As well, IRIs are enclosed in "" instead of <>.

Then try the same query on the web interface at https://dbpedia.org/sparql.
There the datatypes and languages tags do show up.  However, there are some
langStrings without language tags there.


I'm also running into the same problem with a locally installed Virtuoso open
source 7.2.5.

peter






On 08/22/2018 08:15 AM, Kingsley Idehen wrote:
> On 8/22/18 10:24 AM, Peter F. Patel-Schneider wrote:
>> I was hoping to be able to get the SPARQL TSV results format in
>> https://www.w3.org/TR/sparql11-results-csv-tsv/
>>
>> I can probably limp along with explicit language tags and datatypes but 
>> that's
>> a pain to process.
>>
>> peter
> 
> Hi Peter,
> 
> Please share a SPARQL Query Results doc URI that illustrates your
> problem. Then, if fixable, we can reply in kind with a URI that
> demonstrates the fix. 
> 
> 
> 
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

I was hoping to be able to get the SPARQL TSV results format in
https://www.w3.org/TR/sparql11-results-csv-tsv/

I can probably limp along with explicit language tags and datatypes but that's
a pain to process.

peter

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] Virtuoso SPARQL tab separated results with language tags and dataypes

[Peter F. Patel-Schneider]

Is there a way to get Virtuoso to output tab separated or comma separated
results with language tags and data types, as in something like

 "The Cat Returns@en

and

  "2005-01-01"^^xsd:date


peter


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

Hi:

Has there been any progress on handling non-earth coordinates in Virtuoso
(either open source or otherwise)?

peter


On 11/11/2016 10:01 AM, Kingsley Idehen wrote:
> On 11/11/16 12:04 PM, Peter F. Patel-Schneider wrote:
>> My experience is different.  I refreshed virtuoso opensource to the version 
>> of
>> 9 November.  When I tried to load a file with the triple I got an error.
>>
>>
>> idefix /home/virtuoso/var/lib/virtuoso/db> /home/virtuoso/bin/isql  dba 
>> dba
>> Connected to OpenLink Virtuoso
>> Driver: 07.20.3217 OpenLink Virtuoso ODBC Driver
>> OpenLink Interactive SQL (Virtuoso), version 0.9849b.
>> Type HELP; for help and EXIT; to exit.
>> SQL> DELETE FROM DB.DBA.load_list;
>>
>> Done. -- 4 msec.
>> SQL> ld_dir ('/home/local/SoftwareDownloads/wikidata',
>> 'wikidata-mars.ttl', 'http://bkr.nuance.com/wikidata');
>>
>> Done. -- 3 msec.
>> SQL> rdf_loader_run();
>> 08:53:19 PL LOG: Loader started
>> 08:53:19 PL LOG:  File
>> /home/local/SoftwareDownloads/wikidata/wikidata-mars.ttl error 42000 RDFGE:
>> RDF box with a geometry RDF type and a non-geometry content
>> 08:53:19 PL LOG: No more files to load. Loader has finished,
>>
>> Done. -- 8 msec.
>> SQL> idefix /home/virtuoso/var/lib/virtuoso/db>
>> /home/virtuoso/bin/virtuoso-t --version
>> Virtuoso Open Source Edition (Column Store) (multi threaded)
>> Version 7.2.5-dev.3217-pthreads as of Nov  9 2016
>> Compiled for Linux (x86_64-unknown-linux-gnu)
>> Copyright (C) 1998-2016 OpenLink Software
>>
>> I think that the URL for geo: in your file is not one that is recognized by
>> virtuoso as the namespace for the geospatial datatype.
>>
>> wikidata-mars.ttl has
>> @prefix geo: <http://www.opengis.net/ont/geosparql#> .
>> which is taken from the wikidata RDF dump.
>>
>> Your file has
>> @prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> .
>>
>> peter
> 
> Yes, [t]he following isn't being loaded for overzealous reasons:
> @prefix wdt: <http://www.wikidata.org/entity/> .
> @prefix wd: <http://www.wikidata.org/entity1/> .
> @prefix wikibase: <http://www.wikidata.org/entity2/> .
> @prefix geo: <http://www.opengis.net/ont/geosparql#> .
> 
> wd:Q24227 a wikibase:Item ;
>     wdt:P625 " <http://www.wikidata.org/entity/Q111>
> Point(351.83-14.47)"^^gro:wktLiteral .
> 
> It should load, even if Vituoso can't make sense of the geometric context with
> regards to SPARQL queries etc..
> 
> Kingsley
>>
>>
>>> Peter,
>>>
>>> I mispoke about SPARQL and GeoSPARQL. My apologies for the confusion.
>>>
>>> The triple is valid and it loads, as per the simple test I have at:
>>>
>>> http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/Nanotations/test.ttl
>>> .
>>>
>>> or:
>>>
>>>  curl -i
>>> http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/Nanotations/test.ttl
>>>
>>>
>>> Thus, we need to figure out if this is something to do with the version you
>>> are workings with (as my versions are typically hot of the press etc..).
>>>
>>> -- 
>>> Regards,
>>>
>>> Kingsley Idehen   
>>> Founder & CEO 
>>> OpenLink Software   (Home Page: http://www.openlinksw.com)
>>>
>>> Weblogs (Blogs):
>>> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
>>> Blogspot Blog: http://kidehen.blogspot.com
>>> Medium Blog: https://medium.com/@kidehen
>>>
>>> Profile Pages:
>>> Pinterest: https://www.pinterest.com/kidehen/
>>> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
>>> Twitter: https://twitter.com/kidehen
>>> Google+: https://plus.google.com/+KingsleyIdehen/about
>>> LinkedIn: http://www.linkedin.com/in/kidehen
>>>
>>> Web Identities (WebID):
>>> Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this
>>> : 
>>> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
>>>
>>>
>>>
>>> --
>>> Developer Access Program for Intel Xeon Phi Processors
>>> Access to Intel Xeon Phi processor-based developer platforms.
>>> With one year of Intel Parallel Studio XE.
>>> Training and support from Colfax.
>>> Order

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

My experience is different.  I refreshed virtuoso opensource to the version of
9 November.  When I tried to load a file with the triple I got an error.


idefix /home/virtuoso/var/lib/virtuoso/db> /home/virtuoso/bin/isql  dba dba
Connected to OpenLink Virtuoso
Driver: 07.20.3217 OpenLink Virtuoso ODBC Driver
OpenLink Interactive SQL (Virtuoso), version 0.9849b.
Type HELP; for help and EXIT; to exit.
SQL> DELETE FROM DB.DBA.load_list;

Done. -- 4 msec.
SQL> ld_dir ('/home/local/SoftwareDownloads/wikidata',
'wikidata-mars.ttl', 'http://bkr.nuance.com/wikidata');

Done. -- 3 msec.
SQL> rdf_loader_run();
08:53:19 PL LOG: Loader started
08:53:19 PL LOG:  File
/home/local/SoftwareDownloads/wikidata/wikidata-mars.ttl error 42000 RDFGE:
RDF box with a geometry RDF type and a non-geometry content
08:53:19 PL LOG: No more files to load. Loader has finished,

Done. -- 8 msec.
SQL> idefix /home/virtuoso/var/lib/virtuoso/db>
/home/virtuoso/bin/virtuoso-t --version
Virtuoso Open Source Edition (Column Store) (multi threaded)
Version 7.2.5-dev.3217-pthreads as of Nov  9 2016
Compiled for Linux (x86_64-unknown-linux-gnu)
Copyright (C) 1998-2016 OpenLink Software

I think that the URL for geo: in your file is not one that is recognized by
virtuoso as the namespace for the geospatial datatype.

wikidata-mars.ttl has
@prefix geo:  .
which is taken from the wikidata RDF dump.

Your file has
@prefix geo: .

peter


> Peter,
> 
> I mispoke about SPARQL and GeoSPARQL. My apologies for the confusion.
> 
> The triple is valid and it loads, as per the simple test I have at:
> 
> http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/Nanotations/test.ttl
> .
> 
> or:
> 
>  curl -i
> http://kingsley.idehen.net/DAV/home/kidehen/Public/Linked%20Data%20Documents/Nanotations/test.ttl
> 
> 
> Thus, we need to figure out if this is something to do with the version you
> are workings with (as my versions are typically hot of the press etc..).
> 
> -- 
> Regards,
> 
> Kingsley Idehen 
> Founder & CEO 
> OpenLink Software   (Home Page: http://www.openlinksw.com)
> 
> Weblogs (Blogs):
> Legacy Blog: http://www.openlinksw.com/blog/~kidehen/
> Blogspot Blog: http://kidehen.blogspot.com
> Medium Blog: https://medium.com/@kidehen
> 
> Profile Pages:
> Pinterest: https://www.pinterest.com/kidehen/
> Quora: https://www.quora.com/profile/Kingsley-Uyi-Idehen
> Twitter: https://twitter.com/kidehen
> Google+: https://plus.google.com/+KingsleyIdehen/about
> LinkedIn: http://www.linkedin.com/in/kidehen
> 
> Web Identities (WebID):
> Personal: http://kingsley.idehen.net/dataspace/person/kidehen#this
> : 
> http://id.myopenlink.net/DAV/home/KingsleyUyiIdehen/Public/kingsley.ttl#this
> 
> 
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> 
> 
> 
> ___
> Virtuoso-users mailing list
> Virtuoso-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 
@prefix rdf:  .
@prefix xsd:  .
@prefix rdfs:  .
@prefix owl:  .
@prefix wikibase:  .
@prefix wd:  .
@prefix wdt:  .
@prefix geo:  .

wd:Q24227 a wikibase:Item ;
 wdt:P625 " Point(351.83 -14.47)"^^geo:wktLiteral .
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

On 11/11/2016 04:28 AM, Kingsley Idehen wrote:
> On 11/10/16 1:39 PM, Peter F. Patel-Schneider wrote:
>> So when you implied that
>> wd:Q24227 a wikibase:Item ;
>>  wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
>> -14.47)"^^geo:wktLiteral .
>> had an invalid triple you didn't really mean that.
>>
>> peter
> 
> I did, but I was speaking in terms of SPARQL as opposed to GeoSPARQL.
> 
> Kingsley

I am puzzled as to how SPARQL has got into this discussion.  The literal above
is an RDF literal and, as such, should be considered in the context of RDF,
not SPARQL.

As far as RDF is concerned the above literal is valid.  In fact there is no
notion of an invalid literal in RDF at all.  If the datatype of a literal is
not recognized by the RDF implementation then literal is still acceptable.  If
the datatype of a literal is recognized by the RDF implementation and the
lexical value is not in the lexical space of the datatype then the literal is
ill-typed but the implementation still MUST accept it and produce an RDF graph
from it.  To do otherwise is to violate the RDF specification.

This is all spelled out in
https://www.w3.org/TR/rdf11-concepts/#section-Graph-Literal


Peter F. Patel-Schneider
Nuance Communications

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

I modified rdfbox.c to take out the two (!) checks that object to literals of
type geo:wktLiteral with coordinate system URIs.  Currently I'm loading a
wikidata dump into virtuoso and nothing is complaining (so far).

I expect that working with this data will produce query-time errors when
trying to do geographic operations on these values.  Hopefully these errors
will produce SPARQL errors that can be handled and not bring down virtuoso.

peter

PS:  I would be nice to be able to turn the errors into warnings, but I
couldn't figure out how to do that.

PPS:  It also would be nice to have an option that ignores triples with
problems when loading large RDF documents.  I think that this has been asked
for in the past as well.


On 11/10/2016 05:29 AM, Jerven Tjalling Bolleman wrote:
> Dear Kingsley,
> 
> I imagine that Peter is referring to
> 
> Req 10
>All RDFS Literals of type geo:wktLiteral shall consist of an
> optional URI identifying the coordinate reference system followed by
> Simple Features Well Known Text (WKT) describing a geometric value.
> Valid geo:wktLiterals are formed by concatenating a valid,
> absolute URI as defined in [RFC 2396], one or more spaces (Unicode
> U+0020 character) as a separator, and a WKT string as defined in
> Simple Features [ISO 19125-1].
> 
>  From page vii of the GeoSPARQL standard. However, I can imagine that you 
> have
> few customers demanding GeoSPARQL support for Mars at this time ;)
> 
> So it is just a feature not yet implemented...
> 
> Regards,
> Jerven
> 
> On 2016-11-10 14:06, Kingsley Idehen wrote:
>> On 11/9/16 10:25 PM, Peter F. Patel-Schneider wrote:
>>> Through a process of bisection I found the datum that is not handled 
>>> by
>>> virtuoso.  It is
>>>
>>> wd:Q24227 a wikibase:Item ;
>>> wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
>>> -14.47)"^^geo:wktLiteral .
>>>
>>> i.e., a point on Mars.
>>>
>>> Is virtuoso supposed to be able to handle other coordinate systems?  
>>> If not,
>>> how can it handle Wikidata and other information sources that have 
>>> points not
>>> on the surface of the earth?
>>>
>>> peter
>>
>> A valid RDF triple (or datum) would take the form:
>>
>> wd:Q24227 a wikibase:Item ;
>>  wdt:P625 "Point(351.83-14.47)"^^geo:wktLiteral .
>>
>> Thus, you have a problematic triple.
>>
>>
>> Kingsley
>>
>>
>>>
>>>
>>> On 11/08/2016 07:23 PM, Hugh Williams wrote:
>>>> Hi Peter,
>>>>
>>>> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
>>>>
>>>> Against the latest 07.20.3217 build the following point geometry 
>>>> loads
>>>> successfully with the ttlp function:
>>>>
>>>> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
>>>> @prefix
>>>> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  
>>>> geo:geometry
>>>> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
>>>>
>>>> Done. -- 10 msec.
>>>> SQL> sparql select * from  where {?s ?p ?o};
>>>> s
>>>> p
>>>> o
>>>> LONG VARCHAR
>>>> LONG VARCHAR
>>>> LONG VARCHAR
>>>> ___
>>>>
>>>> http://xxx/point
>>>> http://www.w3.org/2003/01/geo/wgs84_pos#geometry
>>>> POINT(1.200476837 22.3961853)
>>>>
>>>> 1 Rows. -- 2 msec.
>>>> SQL>
>>>>
>>>> Best Regards
>>>> Hugh Williams
>>>> Professional Services
>>>> OpenLink Software, Inc.  //  
>>>> http://www.openlinksw.com/
>>>> Weblog   -- http://www.openlinksw.com/blogs/
>>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>>> Twitter  -- http://twitter.com/OpenLink
>>>> Google+  -- http://plus.google.com/100570109519069333827/
>>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>>> Universal Data Access, Integration, and Management Technology 
>>>> Providers
>>>>
>>>>> On 9 Nov 2016, at 02:34, Peter F. Patel-Schneider 
>>>>> >>>> <mailto:pfpschnei...@gmail.com>> wrote:
>>>>>
>>>>> Hi:
>>>>&g

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

So when you implied that
wd:Q24227 a wikibase:Item ;
 wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
-14.47)"^^geo:wktLiteral .
had an invalid triple you didn't really mean that.

peter



On 11/10/2016 10:24 AM, Kingsley Idehen wrote:
> On 11/10/16 12:13 PM, Peter F. Patel-Schneider wrote:
>> Is the problem that there is <> around the URI in
>>   <http://www.wikidata.org/entity/Q111> Point(351.83 -14.47)
>> Otherwise this is in the lexical space for geo:wktLiteral.
>>
>> Although the spec for geo:wktLiteral says that the lexical space consists of
>> an optional URI followed by a geometric value, the examples in the spec
>> enclose the URIs in <>.  I would expect that implementations of 
>> geo:wktLiteral
>> would thus allow enclosing <>.
>>
>> Peter F. Patel-Schneider
>> Nuance Communications
> 
> Hi Peter,
> 
> We don't support this GeoSPARQL notation for datum representation at
> this time. We do plan to get this added in the not too distant future. I
> just can't give a specific ETA at this point in time.
> 
> Kingsley 
>>
>> On 11/10/2016 05:06 AM, Kingsley Idehen wrote:
>>> On 11/9/16 10:25 PM, Peter F. Patel-Schneider wrote:
>>>> Through a process of bisection I found the datum that is not handled by
>>>> virtuoso.  It is
>>>>
>>>> wd:Q24227 a wikibase:Item ;
>>>>wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
>>>> -14.47)"^^geo:wktLiteral .
>>>>
>>>> i.e., a point on Mars.
>>>>
>>>> Is virtuoso supposed to be able to handle other coordinate systems?  If 
>>>> not,
>>>> how can it handle Wikidata and other information sources that have points 
>>>> not
>>>> on the surface of the earth?
>>>>
>>>> peter
>>> A valid RDF triple (or datum) would take the form:
>>>
>>> wd:Q24227 a wikibase:Item ;
>>> wdt:P625 "Point(351.83-14.47)"^^geo:wktLiteral .
>>>
>>> Thus, you have a problematic triple. 
>>>
>>>
>>> Kingsley
>>>
>>>
>>>>
>>>> On 11/08/2016 07:23 PM, Hugh Williams wrote:
>>>>> Hi Peter,
>>>>>
>>>>> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
>>>>>
>>>>> Against the latest 07.20.3217 build the following point geometry loads
>>>>> successfully with the ttlp function:
>>>>>
>>>>> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> 
>>>>> @prefix
>>>>> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  geo:geometry
>>>>> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
>>>>>
>>>>> Done. -- 10 msec.
>>>>> SQL> sparql select * from  where {?s ?p ?o};
>>>>> s 
>>>>>
>>>>> p 
>>>>>
>>>>> o
>>>>> LONG VARCHAR  
>>>>>
>>>>> LONG VARCHAR  
>>>>>
>>>>> LONG VARCHAR
>>>>> ___
>>>>>
>>>>> http://xxx/point  
>>>>>
>>>>> http://www.w3.org/2003/01/geo/wgs84_pos#geometry  
>>>>>
>>>>> POINT(1.200476837 22.3961853)
>>>>>
>>>>> 1 Rows. -- 2 msec.
>>>>> SQL> 
>>>>>
>>>>> Best Regards
>>>>> Hugh Williams
>>>>> Professional Services
>>>>> OpenLink Software, Inc.  //  http://www.openlinksw.com/
>>>>> Weblog   -- http://www.openlinksw.com/blogs/
>>>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>>>> Twitter  -- http://twitter.com/OpenLink
>>>>> Google+  -- http://plus.google.com/100570109519069333827/
>>>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>>>> Universal Data Access, Integratio

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

Is the problem that there is <> around the URI in
  <http://www.wikidata.org/entity/Q111> Point(351.83 -14.47)
Otherwise this is in the lexical space for geo:wktLiteral.

Although the spec for geo:wktLiteral says that the lexical space consists of
an optional URI followed by a geometric value, the examples in the spec
enclose the URIs in <>.  I would expect that implementations of geo:wktLiteral
would thus allow enclosing <>.

Peter F. Patel-Schneider
Nuance Communications

On 11/10/2016 05:06 AM, Kingsley Idehen wrote:
> On 11/9/16 10:25 PM, Peter F. Patel-Schneider wrote:
>> Through a process of bisection I found the datum that is not handled by
>> virtuoso.  It is
>>
>> wd:Q24227 a wikibase:Item ;
>>  wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
>> -14.47)"^^geo:wktLiteral .
>>
>> i.e., a point on Mars.
>>
>> Is virtuoso supposed to be able to handle other coordinate systems?  If not,
>> how can it handle Wikidata and other information sources that have points not
>> on the surface of the earth?
>>
>> peter
> 
> A valid RDF triple (or datum) would take the form:
> 
> wd:Q24227 a wikibase:Item ;
>   wdt:P625 "Point(351.83-14.47)"^^geo:wktLiteral .
> 
> Thus, you have a problematic triple. 
> 
> 
> Kingsley
> 
> 
>>
>>
>> On 11/08/2016 07:23 PM, Hugh Williams wrote:
>>> Hi Peter,
>>>
>>> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
>>>
>>> Against the latest 07.20.3217 build the following point geometry loads
>>> successfully with the ttlp function:
>>>
>>> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> @prefix
>>> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  geo:geometry
>>> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
>>>
>>> Done. -- 10 msec.
>>> SQL> sparql select * from  where {?s ?p ?o};
>>> s   
>>>  
>>> p   
>>>  
>>> o
>>> LONG VARCHAR
>>>  
>>> LONG VARCHAR
>>>  
>>> LONG VARCHAR
>>> ___
>>>
>>> http://xxx/point
>>>  
>>> http://www.w3.org/2003/01/geo/wgs84_pos#geometry
>>>  
>>> POINT(1.200476837 22.3961853)
>>>
>>> 1 Rows. -- 2 msec.
>>> SQL> 
>>>
>>> Best Regards
>>> Hugh Williams
>>> Professional Services
>>> OpenLink Software, Inc.  //  http://www.openlinksw.com/
>>> Weblog   -- http://www.openlinksw.com/blogs/
>>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>>> Twitter  -- http://twitter.com/OpenLink
>>> Google+  -- http://plus.google.com/100570109519069333827/
>>> Facebook -- http://www.facebook.com/OpenLinkSoftware
>>> Universal Data Access, Integration, and Management Technology Providers
>>>
>>>> On 9 Nov 2016, at 02:34, Peter F. Patel-Schneider >>> <mailto:pfpschnei...@gmail.com>> wrote:
>>>>
>>>> Hi:
>>>>
>>>> I'm trying to get virtuoso to work with geometry data types.
>>>>
>>>> I noticed that the version of virtuoso that I am using requires that the 
>>>> data
>>>> type names be in ALL CAPS (e.g., POINT).   Has this been fixed in the 
>>>> current
>>>> version of virtuoso?
>>>>
>>>> peter
>>>>
>>>> --
>>>> Developer Access Program for Intel Xeon Phi Processors
>>>> Access to Intel Xeon Phi processor-based developer platforms.
>>>> With one year of Intel Parallel Studio XE.
>>>> Training and support from Colfax.
>>>> Order your platform today. http://sdm.link/xeonphi
>>>> ___
>>>> Virtuoso-users mailing list
>>>> Virtuoso-users@lists.sourceforge.net
>>>> <mailto:Virtuo

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

Through a process of bisection I found the datum that is not handled by
virtuoso.  It is

wd:Q24227 a wikibase:Item ;
wdt:P625 "<http://www.wikidata.org/entity/Q111> Point(351.83
-14.47)"^^geo:wktLiteral .

i.e., a point on Mars.

Is virtuoso supposed to be able to handle other coordinate systems?  If not,
how can it handle Wikidata and other information sources that have points not
on the surface of the earth?

peter


On 11/08/2016 07:23 PM, Hugh Williams wrote:
> Hi Peter,
> 
> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
> 
> Against the latest 07.20.3217 build the following point geometry loads
> successfully with the ttlp function:
> 
> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> @prefix
> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  geo:geometry
> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
> 
> Done. -- 10 msec.
> SQL> sparql select * from  where {?s ?p ?o};
> s
> p
> o
> LONG VARCHAR 
> LONG VARCHAR 
> LONG VARCHAR
> ___
> 
> http://xxx/point 
> http://www.w3.org/2003/01/geo/wgs84_pos#geometry 
> POINT(1.200476837 22.3961853)
> 
> 1 Rows. -- 2 msec.
> SQL> 
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc.  //  http://www.openlinksw.com/
> Weblog   -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
>> On 9 Nov 2016, at 02:34, Peter F. Patel-Schneider > <mailto:pfpschnei...@gmail.com>> wrote:
>>
>> Hi:
>>
>> I'm trying to get virtuoso to work with geometry data types.
>>
>> I noticed that the version of virtuoso that I am using requires that the data
>> type names be in ALL CAPS (e.g., POINT).   Has this been fixed in the current
>> version of virtuoso?
>>
>> peter
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> <mailto:Virtuoso-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] geometry error when loading Wikidata dump

[Peter F. Patel-Schneider]

OK. Now I get further, but when loading a wikidata dump there is still an
error in the log

17:58:17 PL LOG: Loader started
17:58:38 PL LOG:  File
/home/local/SoftwareDownloads/wikidata/wikidata-20161031-all-BETA.ttl.gz error
42000 RDFGE: RDF box with a geometry RDF type and a non-geometry content
17:58:38 PL LOG: No more files to load. Loader has finished,

How can I find out what part of the input caused this problem?

peter



On 11/08/2016 07:23 PM, Hugh Williams wrote:
> Hi Peter,
> 
> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
> 
> Against the latest 07.20.3217 build the following point geometry loads
> successfully with the ttlp function:
> 
> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> @prefix
> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  geo:geometry
> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
> 
> Done. -- 10 msec.
> SQL> sparql select * from  where {?s ?p ?o};
> s
> p
> o
> LONG VARCHAR 
> LONG VARCHAR 
> LONG VARCHAR
> ___
> 
> http://xxx/point 
> http://www.w3.org/2003/01/geo/wgs84_pos#geometry 
> POINT(1.200476837 22.3961853)
> 
> 1 Rows. -- 2 msec.
> SQL> 
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc.  //  http://www.openlinksw.com/
> Weblog   -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
>> On 9 Nov 2016, at 02:34, Peter F. Patel-Schneider > <mailto:pfpschnei...@gmail.com>> wrote:
>>
>> Hi:
>>
>> I'm trying to get virtuoso to work with geometry data types.
>>
>> I noticed that the version of virtuoso that I am using requires that the data
>> type names be in ALL CAPS (e.g., POINT).   Has this been fixed in the current
>> version of virtuoso?
>>
>> peter
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> <mailto:Virtuoso-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

Re: [Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

It's ancient (2015).  I'll upgrade.

peter


On 11/08/2016 07:23 PM, Hugh Williams wrote:
> Hi Peter,
> 
> What is the Virtuoso version your are using ( run “virtuoso-t -?”) ?
> 
> Against the latest 07.20.3217 build the following point geometry loads
> successfully with the ttlp function:
> 
> SQL> ttlp ('@prefix geo: <http://www.w3.org/2003/01/geo/wgs84_pos#> @prefix
> virtrdf: <http://www.openlinksw.com/schemas/virtrdf#>  geo:geometry
> "point(1.2 22.4"^^virtrdf:Geometry .', 'xxx', 'graph');
> 
> Done. -- 10 msec.
> SQL> sparql select * from  where {?s ?p ?o};
> s
> p
> o
> LONG VARCHAR 
> LONG VARCHAR 
> LONG VARCHAR
> ___
> 
> http://xxx/point 
> http://www.w3.org/2003/01/geo/wgs84_pos#geometry 
> POINT(1.200476837 22.3961853)
> 
> 1 Rows. -- 2 msec.
> SQL> 
> 
> Best Regards
> Hugh Williams
> Professional Services
> OpenLink Software, Inc.  //  http://www.openlinksw.com/
> Weblog   -- http://www.openlinksw.com/blogs/
> LinkedIn -- http://www.linkedin.com/company/openlink-software/
> Twitter  -- http://twitter.com/OpenLink
> Google+  -- http://plus.google.com/100570109519069333827/
> Facebook -- http://www.facebook.com/OpenLinkSoftware
> Universal Data Access, Integration, and Management Technology Providers
> 
>> On 9 Nov 2016, at 02:34, Peter F. Patel-Schneider > <mailto:pfpschnei...@gmail.com>> wrote:
>>
>> Hi:
>>
>> I'm trying to get virtuoso to work with geometry data types.
>>
>> I noticed that the version of virtuoso that I am using requires that the data
>> type names be in ALL CAPS (e.g., POINT).   Has this been fixed in the current
>> version of virtuoso?
>>
>> peter
>>
>> --
>> Developer Access Program for Intel Xeon Phi Processors
>> Access to Intel Xeon Phi processor-based developer platforms.
>> With one year of Intel Parallel Studio XE.
>> Training and support from Colfax.
>> Order your platform today. http://sdm.link/xeonphi
>> ___
>> Virtuoso-users mailing list
>> Virtuoso-users@lists.sourceforge.net
>> <mailto:Virtuoso-users@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/virtuoso-users
> 

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users

[Virtuoso-users] geometry data type in virtuoso

[Peter F. Patel-Schneider]

Hi:

I'm trying to get virtuoso to work with geometry data types.

I noticed that the version of virtuoso that I am using requires that the data
type names be in ALL CAPS (e.g., POINT).   Has this been fixed in the current
version of virtuoso?

peter

--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Virtuoso-users mailing list
Virtuoso-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/virtuoso-users