NodeFactoryExtra: XSDinteger vs XSDint

[DAVID MOLINA ESTRADA]

Hi,

Why the class NodeFactoryExtra (In api jena 3.8.0, 
org.apache.jena.sparql.util.NodeFactoryExtra) converts a int/long into a 
XSDinteger, but XSDint into int. The problem that I have is with the first one. 
In anothers API Jena and Fuseki versions, a int was converted into XSDint, and 
now is a XSDinteger, so some sparql doesn't work.

public static Node intToNode(int integer) {
return NodeFactory.createLiteral(Integer.toString(integer), 
XSDDatatype.XSDinteger) ;
}

public static int nodeToInt(Node node) {
LiteralLabel lit = node.getLiteral() ;

if ( !XSDDatatype.XSDint.isValidLiteral(lit) )
return Integer.MIN_VALUE ;
int i = ((Number)lit.getValue()).intValue() ;
return i ;
}

Thanks for all
 
David Molina Estrada
 Software Architect
  



Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary

Re: [MASSMAIL]Re: Splitting data into graphs vs datasets

[DAVID MOLINA ESTRADA]

In my opinion, a graph is like a schema in relational database, and a dataset 
is like a database instance.

Regards,
David 

-Daan Reid  escribió: -
Para: users@jena.apache.org
De: Daan Reid 
Fecha: 22/03/2018 11:35
Asunto: [MASSMAIL]Re: Splitting data into graphs vs datasets

I would say that using separate datasets is a good idea if you have sets 
of graphs that just don't belong together. The dataset as an 
organisational, abstract container is an excellent idea, in my opinion.

Regards,

Daan

On 22-03-18 11:22, Mikael Pesonen wrote:
> Ok seems that using many datasets is not a good idea. I had no bias and 
> not having any issues with speed, just wanted to see what is best way to 
> go.
> 
> On 21.3.2018 20:48, ajs6f wrote:
>>>   Those sure are good reasons for using named graphs. But what about 
>>> using different datasets too?
>> Consider that you may not be seeing such reasons because it may not 
>> actually be as good an idea.
>>
>> Here's another reason to prefer graphs: There is a standard management 
>> HTTP API for named graphs: SPARQL Graph Store. There is no equivalent 
>> for datasets, so each product rolls its own. That's not good for 
>> flexibility if you have to move products.
>>
>> As for performance, that will depend radically on the implementation. 
>> Jena TIM, for example, using hashing for its indexes, so the 
>> difference between having a lot of quads in a dataset and a few isn't 
>> likely to be that much. Other impls will vary.
>>
>> Are you sure that performance is going to be improved by separating 
>> out datasets? (I.e. is that the measured bottleneck?) Are you now 
>> having problems with queries accidentally querying data they shouldn't 
>> see, and can your queries be rewritten to fix that (which might also 
>> improve performance)? (Jena has a permissions framework that can 
>> secure information down to the individual triple.)
>>
>> ajs6f
>>
>>> On Mar 21, 2018, at 6:35 AM, Mikael Pesonen 
>>>  wrote:
>>>
>>>
>>> Those sure are good reasons for using named graphs. But what about 
>>> using different datasets too?
>>>
>>> btw, I couldn't find info on how to run many datasets with Fuseki. is 
>>> it just one dataset per fuseki process? -loc parameter for 
>>> fuseki-server.jar?
>>>
>>> Br
>>>
>>> On 20.3.2018 14:22, Martynas Jusevičius wrote:
 Provenance. With named graphs, it's easier to track where data came 
 from:
 who imported it, when etc.
 You can also have meta-graphs about other graphs.

 Also editing and updating data. You can load named graph contents (of
 smallish size) in an editor, make changes and then store a new 
 version in
 the same graph. You probably would not want to do this with a large 
 default
 graph.

 On Tue, Mar 20, 2018 at 1:16 PM, Mikael Pesonen 
 
 wrote:

> Hi,
>
> I'm using Fuseki GSP, and so far have put all data into one default
> dataset and using graphs to split it.
>
> If I'm right there would be benefits using more than one dataset
> - better performance - each query is done inside a dataset so less 
> data =
> faster query
> - protection of data - can't "accidentaly" query data from other 
> datasets
> Downsides:
> - combining data from various datasets is heavier task
>
> Is this correct? Any other things that should be considered?
>
> Thank you
>
> -- 
> Lingsoft - 30 years of Leading Language Management
>
> www.lingsoft.fi
>
> Speech Applications - Language Management - Translation - Reader's and
> Writer's Tools - Text Tools - E-books and M-books
>
> Mikael Pesonen
> System Engineer
>
> e-mail: mikael.peso...@lingsoft.fi
> Tel. +358 2 279 3300
>
> Time zone: GMT+2
>
> Helsinki Office
> Eteläranta 10
> 
> FI-00130 Helsinki
> FINLAND
>
> Turku Office
> Kauppiaskatu 5 A
> 
> FI-20100 Turku
> FINLAND
>
>
>>> -- 
>>> Lingsoft - 30 years of Leading Language Management
>>>
>>> www.lingsoft.fi
>>>
>>> Speech Applications - Language Management - Translation - Reader's 
>>> and Writer's Tools - Text Tools - E-books and M-books
>>>
>>> Mikael Pesonen
>>> System Engineer
>>>
>>> e-mail: mikael.peso...@lingsoft.fi
>>> Tel. +358 2 279 3300
>>>
>>> Time zone: GMT+2
>>>
>>> Helsinki Office
>>> Eteläranta 10
>>> FI-00130 Helsinki
>>> FINLAND
>>>
>>> Turku Office
>>> Kauppiaskatu 5 A
>>> FI-20100 Turku
>>> FINLAND
>>>
> 

Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary

Re: fuseki in HA

[DAVID MOLINA ESTRADA]

Hi Andy,

In the next few days I will study your proposal and the diferents posibilities.


Thank you


  David Molina Estrada

  Software Architect

-Andy Seaborne <a...@apache.org> escribió: -
Para: users@jena.apache.org
De: Andy Seaborne <a...@apache.org>
Fecha: 22/02/2018 13:15
Asunto: [MASSMAIL]Re: fuseki in HA

Hi David,

This is one of the main use cases for:

https://afs.github.io/rdf-delta/

and there is a Fuseki-component in that build that incorporates the 
mechanism need for 2+ Fuseki's to propagate changes [3] (a custom 
service /dataset/patch that accepts patch files and applied them).

The work has two parts - the data format need to propagate change (RDF 
Patch [1]) and a patch log server [2].

Keeping these two components separate is import because not all 
situations will want patch server.  Distribution using  Hazelcast or 
Kafka, or publish changes in the style of Atom/RSS, being good examples. 
By having a defined patch format, there is no reason why the various 
triplestores even have to be all Jena-based.

Apache Licensed, not part of the Jena project.

Let me know what you think:

 Andy

[1] https://afs.github.io/rdf-delta/rdf-patch.html
[2] https://afs.github.io/rdf-delta/rdf-patch-logs.html
[3] https://github.com/afs/rdf-delta/tree/master/rdf-delta-fuseki

Disclosure : this part of my $job at TopQuadrant.

There is not reason not to start publishing it to maven central - I just 
haven't had the need to so far.

The RDF patch work is based on previous work with Rob Vesse.

On 21/02/18 12:32, DAVID MOLINA ESTRADA wrote:
> Hi,
> 
> I want to buid a HA web Application based on fuseki server in HA too. My idea 
> is create a fuseki docker and deploy so instance that I need. For querying 
> all is Ok, but I try to define a mechanism (it may be based in Topics with 
> Hazelcast or Kafka) to distribute changes to all nodes (Both uploading files 
> and SparQL updated).
> 
> Any recommandation or best practise? Has somebody done anything similar?
> 
> Thanks
> 
>   
> David Molina Estrada
> 
>
> Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
> aquest missatge si no és estrictament necessari | Avoid printing this message 
> if it is not absolutely necessary
> 

Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary

fuseki in HA

[DAVID MOLINA ESTRADA]

Hi,

I want to buid a HA web Application based on fuseki server in HA too. My idea 
is create a fuseki docker and deploy so instance that I need. For querying all 
is Ok, but I try to define a mechanism (it may be based in Topics with 
Hazelcast or Kafka) to distribute changes to all nodes (Both uploading files 
and SparQL updated).

Any recommandation or best practise? Has somebody done anything similar?

Thanks  

 
David Molina Estrada

  
Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary

Removig persitent dataset in Fuseki 3.4.0 doen't work

[DAVID MOLINA ESTRADA]

Hi,

When a persistent dataset is deleted from Fuseki WEB GUI, the dataset folder in 
fuseki's databases folder and the dataset config ttl file in fuseki's 
configuration folder remain. 

I am running a Fuseki.war 3.4.0 in a Tomcat. Then, when i restart the Tomcat 
server, the deleted dataset reappears.

Thank you,
David Molina
Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary

Backup doen't work with Fuseki 3.4.0

[DAVID MOLINA ESTRADA]

Hi,

I am running a Fuseki.war 3.4.0 in a Tomcat. With the previous version, 2.6.0, 
I can do backup from Fuseki web console but after upgrading backup doen't work. 
I don't get any error, the application reponses as if everything was fine: 
"Task backup started at 2017-10-13T12:15:17.431+02:00, finished at 
2017-10-13T12:15:17.433+02:00". 


In log file, I can see:


[2017-10-13 12:15:17] Admin  INFO  [3] POST 
http://localhost:8080/fuseki/$/backup/ontofarma
[2017-10-13 12:15:17] Admin  INFO  [3] Backup dataset /ontofarma
[2017-10-13 12:15:17] Server INFO  Task : 1 : backup
[2017-10-13 12:15:17] Server INFO  [Task 1] starts : backup
[2017-10-13 12:15:17] Admin  INFO  [3] 200 OK (4 ms)
[2017-10-13 12:15:17] Server INFO  [Task 1] finishes : backup
[2017-10-13 12:15:17] Server INFO  [4] GET 
http://localhost:8080/fuseki/$/tasks/1
[2017-10-13 12:15:17] Server INFO  [4] Task 1
[2017-10-13 12:15:17] Server INFO  [4] 200 OK (0 ms)


But, the backup folder is empty.

Thank you,
David Molina

Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary
Evite imprimir este mensaje si no es estrictamente necesario | Eviti imprimir 
aquest missatge si no és estrictament necessari | Avoid printing this message 
if it is not absolutely necessary