DatasetGraph, Context serialization and thrift implementation, BNode distribution/collision.

[Dick Murray]

Hi.

Question regarding the design thoughts behind Context and the callbacks.
Also merging BNodes...

I have implemented a Thrift based RPC DatasetGraph consisting of a Client
(implements DatasetGraph) which forwards calls to an IFace (generated from
a Thrift file which closely mimics the DatasetGraph interface with some
method name tweaks to handle thrift nuances such as not supporting method
overloading). The IFace wraps a DatasetGraph.

The IFace supports all of the DatasetGraph interface (including RPC lock
and transaction support) with the exception of getContext(), currently it
returns Context.emptyContext. Context and Symbol don't implement
Serializable, which in itself can be overcome. But I stumped at the
callback part of Context. What is it? What does it do? (besides the
obvious!).

In the bigger picture I implement a distributed DatasetGraph which contains
a set of IFace endpoints. Thus when find(Quad) is called it makes a set of
RPC calls to the IFace endpoints and aggregates the results. Internally
locks are applied when needed, in particular write locks are weighted e.g.
add(x, s, p, o) will attempt to lock the IFace which has graph x (i.e. it
checks for the graph before doing the write lock and add). Basically
beginTransaction(ReadWrite) on the DatsetGraphDistributed won't actually
call beginTransaction(ReadWrite) on an IFace until it needs to. This allows
multiple IFace endpoints to be in write transactions. To support the thread
affinity of DatasetGraph the IFace endpoints use a UUID to delegate from
the Thrift thread pool thread (i.e. the one servicing the RPC call) to the
same thread which actually performs the wrapped DatasetGraph action.
Additionally the underlying DatasetGraph can be accessed as usual whilst
being wrapped by the IFace which supports RPC calls into the same
DatasetGraph.

Anyway...

What was the Context callback designed for? Is it ever used?

If I have a central Context which I push to the IFace endpoints would that
cause me any issues? Similar idea to a central config...

Will BNodes in two DatasetGraph's ever collide?

Dick.

RE: Fuseki / ARQ DESCRIBE query to include ?s ?p

[Beetz, J.]

Dear A. Soroka, 
Thank you for the quick reply.

> I'm not sure what you mean by such triples as "(?s ?p  and
> probably (?s  ?o). "
> 
> Can you give some concrete examples?

Suppose I have a graph:

@prefix foo: 

foo:Foo a owl:Class ;
rdfs:label "The Foo concept"@en . 

foo:Bar a owl:Class ;
rdfs:label "The Bar concept"@en ;
foo:has_part foo:Foo .

foo:has_part a owl:ObjectProperty ;

When doing a standard 

DESCRIBE  

on the my Fuseki SPARQL endpoint, I get the answer

foo:Foo rdf:type owl:Class .
foo:Foo rdfs:label "The Foo concept"@en .

but not 

foo:Bar foo:has_part foo:Foo .

since only triples are returned where the  
resource is the subject ( ?p ?o) not where it  is the object (?s ?p ) 
or predicate (?s  ?o)

I could navigate to foo:Bar by inserting foo:part_of as a reverse relationship 
to foo:has_part but do would like to avoid these additional triples in the 70k 
triple data set. 

I hope my question became somewhat clearer.

Thanks
Jakob
___
Dr. Jakob Beetz - Assistant Professor 
Information Systems in the Built Environment (ISBE) Group
Department of the Built Environment | Bouwkunde
Eindhoven University of Technology, The Netherlands
phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06

> ---
> A. Soroka
> The University of Virginia Library
> 
> > On Mar 3, 2017, at 5:13 AM, Beetz, J.  wrote:
> >
> > Dear community,
> >
> > I have set up a Pubby http://wifo5-03.informatik.uni-mannheim.de/pubby/
> frontend to allow dereferencing/content-negotiation/browser-navigation of a
> vocabulary served by Fuseki 2.4.1 .
> > As per the SPARQL standard, the default behavior of DESCRIBE queries that 
> > are
> sent by the frontend to Fuseki is left to the implementation. Fusekis default
> behavior is to send back the graph containing all triples where  resource> is the subject ( ?p ?o). I would also like to
> include (?s ?p  and probably (?s  ?o).
> >
> > From the list archive I have seen that I can probably implement my own
> execDescribe() similar to this thread from some time ago:
> >
> http://jena.markmail.org/message/5thzze4xhqhak34g?q=describe+query+%3Fs+%3Fp+%3
> Fo=2#query:describe%20query%20%3Fs%20%3Fp%20%3Fo+page:2+mid:5thzze4xhqhak3
> 4g+state:results
> >
> > I wonder whether there is another (easier) way through a configuration
> setting or similar which allows me to achieve this.
> >
> > Thank you very much in advance for your help
> >
> > Jakob
> >
> > ___
> > Dr. Jakob Beetz - Assistant Professor
> > Information Systems in the Built Environment (ISBE) Group
> > Department of the Built Environment | Bouwkunde
> > Eindhoven University of Technology, The Netherlands
> > phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06
> >

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

[anuj kumar]

Hey,
 I just saw https://issues.apache.org/jira/browse/JENA-1301
Should we not first officially deprecate it and gives any users of Solr a
chance to move to different Indexing technology?

BTW, I dont know yet how to login to apache JIRA.

Thanks,
Anuj Kumar

On Fri, Mar 3, 2017 at 1:23 PM, anuj kumar  wrote:

> I Osma,
>  I briefly looked at the pull request. I beieve we need to upgrade Lucene
> and Solr in one go, isnt it. The reason being Solr 4.9.1 depends on Lucene
> 4.9.1
>
> Also how do i log into  issues.apache.org and where to file this bug?
>
> Thanks,
> Anuj Kumar
>
> On Fri, Mar 3, 2017 at 11:22 AM, Osma Suominen 
> wrote:
>
>> Hi Anuj,
>>
>> It's great that we found agreement over this!
>>
>> I've restarted the Lucene upgrade effort (JENA-1250) that had stalled and
>> made a PR [1] that implements the upgrade up to version 6.4.1 (with 5.5.4
>> as an intermediate step). I'll wait for comments on the PR and if people
>> think it's OK I will merge it soon to Jena master. Meanwhile, you can
>> already base your ES implementation on that branch [2] if you like.
>>
>> Could you please open a JIRA issue on issues.apache.org explaining the
>> Elasticsearch support feature, so that we have a place for tracking this
>> work, request comments etc.
>>
>> Also I suggest we move the discussion around this to the developers' list
>> (d...@jena.apache.org) where it's more appropriate.
>>
>> -Osma
>>
>> [1] https://github.com/apache/jena/pull/219
>>
>> [2] https://github.com/osma/jena/tree/jena-1250-lucene6
>>
>>
>> 03.03.2017, 02:45, anuj kumar kirjoitti:
>>
>>> I second that. I am now finalising the integration of ES and should have
>>> a
>>> good production quality implementation ready in a week's time.  At that
>>> time I would want you guys to have a look at the implementation and
>>> provide
>>> feedback. Once you guys have upgraded Lucene to 6.4.1 , I can merge the
>>> code in jena-text module and do a round of testing.
>>>
>>> Thanks,
>>> Anuj Kumar
>>>
>>> On 2 Mar 2017 22:28, "A. Soroka"  wrote:
>>>
>>> I do agree that trying to juggle different versions of Lucene libraries
 is
 probably not a realistic option right now. Luckily (if I understand the
 conversation thus far correctly) we have a solid alternative; getting
 our
 current Lucene dependency upgraded should allow us to (eventually) merge
 Anuj's work into the mainstream of development. Someone please tell me
 if I
 have that wrong! :grin:

 Let me reiterate that this seems like very good work and speaking for
 myself, I certainly want to get it included into Jena. It's just a
 question
 of fitting it in correctly, which might take a bit of time.

 ---
 A. Soroka
 The University of Virginia Library

 On Mar 1, 2017, at 1:27 PM, Osma Suominen 
>
 wrote:

>
> Hi Anuj!
>
> I have nothing against modularity in general. However, I cannot see how
>
 your proposal could work in practice for the Fuseki build, due to the
 reasons I mentioned in my previous message (and Adam seemed to concur).

>
> In any case, I'll see what I can do to get the Lucene upgrade moving
>
 again. If all current Jena modules (ie jena-text and jena-spatial) were
 upgraded to Lucene 6.4.1, then you could just add your ES classes to
 jena-text, right? I think that would be better for everyone than having
 to
 maintain your own separate module.

>
> -Osma
>
> 01.03.2017, 16:59, anuj kumar kirjoitti:
>
>> I personally have no preference as to how the code in Jena should be
>> structured, as long as I am able to use it :).
>> I have personal preference of doing it in a specific way because IMO,
>>
> it is

> modular which makes it much easier to maintain in the long run. But
>>
> again

> it may not be the quickest one.
>>
>> I already have been given a deadline, by the company to have ES
>>
> extension

> implemented in the next 15 days :). What this means is that I will be
>> maintaining the ES code extension to Jena Text at-least locally for a
>> coming period of time. I would be more than happy to contribute to
>> Jena
>> community whatever is required to have a proper ElasticSearch
>> Implementation in place, whether within jena-text module or as a
>>
> separate

> module. Till the time Lucene and Solr is not upgraded to the latest
>> version, I will have to maintain a separate module for jena-text-es.
>>
>> Cheers!
>> Anuj Kumar
>>
>>
>> On Wed, Mar 1, 2017 at 3:36 PM, A. Soroka  wrote:
>>
>> Osma--
>>>
>>> The short answer is that yes, given the right tools you _can_ have
>>> different versions of code accessible in different ways. 

Re: Fuseki / ARQ DESCRIBE query to include ?s ?p

[A. Soroka]

No, Pubby [1] is designed to present a simple "Linked Data" representation of 
resources the data for which are recorded in some SPARQL-equipped service (e.g. 
Fuseki).

You set up Pubby aimed at your SPARQL endpoint, and then when people make 
requests for a particular resource from Pubby, it gives them the results of a 
DESCRIBE query on that resource.

---
A. Soroka
The University of Virginia Library

[1]

> On Mar 3, 2017, at 9:37 AM, Martynas Jusevičius  wrote:
> 
> Isn't Fuseki already doing the same as Pubby?
> 
> On Fri, Mar 3, 2017 at 11:13 AM, Beetz, J.  wrote:
>> Dear community,
>> 
>> I have set up a Pubby http://wifo5-03.informatik.uni-mannheim.de/pubby/ 
>> frontend to allow dereferencing/content-negotiation/browser-navigation of a 
>> vocabulary served by Fuseki 2.4.1 .
>> As per the SPARQL standard, the default behavior of DESCRIBE queries that 
>> are sent by the frontend to Fuseki is left to the implementation. Fusekis 
>> default behavior is to send back the graph containing all triples where 
>>  is the subject ( ?p ?o). I would also 
>> like to include (?s ?p  and probably (?s > resource> ?o).
>> 
>> From the list archive I have seen that I can probably implement my own 
>> execDescribe() similar to this thread from some time ago:
>> http://jena.markmail.org/message/5thzze4xhqhak34g?q=describe+query+%3Fs+%3Fp+%3Fo=2#query:describe%20query%20%3Fs%20%3Fp%20%3Fo+page:2+mid:5thzze4xhqhak34g+state:results
>> 
>> I wonder whether there is another (easier) way through a configuration 
>> setting or similar which allows me to achieve this.
>> 
>> Thank you very much in advance for your help
>> 
>> Jakob
>> 
>> ___
>> Dr. Jakob Beetz - Assistant Professor
>> Information Systems in the Built Environment (ISBE) Group
>> Department of the Built Environment | Bouwkunde
>> Eindhoven University of Technology, The Netherlands
>> phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06
>> 

Re: Fuseki / ARQ DESCRIBE query to include ?s ?p

[Martynas Jusevičius]

Isn't Fuseki already doing the same as Pubby?

On Fri, Mar 3, 2017 at 11:13 AM, Beetz, J.  wrote:
> Dear community,
>
> I have set up a Pubby http://wifo5-03.informatik.uni-mannheim.de/pubby/ 
> frontend to allow dereferencing/content-negotiation/browser-navigation of a 
> vocabulary served by Fuseki 2.4.1 .
> As per the SPARQL standard, the default behavior of DESCRIBE queries that are 
> sent by the frontend to Fuseki is left to the implementation. Fusekis default 
> behavior is to send back the graph containing all triples where  resource> is the subject ( ?p ?o). I would also like to 
> include (?s ?p  and probably (?s  ?o).
>
> From the list archive I have seen that I can probably implement my own 
> execDescribe() similar to this thread from some time ago:
> http://jena.markmail.org/message/5thzze4xhqhak34g?q=describe+query+%3Fs+%3Fp+%3Fo=2#query:describe%20query%20%3Fs%20%3Fp%20%3Fo+page:2+mid:5thzze4xhqhak34g+state:results
>
> I wonder whether there is another (easier) way through a configuration 
> setting or similar which allows me to achieve this.
>
> Thank you very much in advance for your help
>
> Jakob
>
> ___
> Dr. Jakob Beetz - Assistant Professor
> Information Systems in the Built Environment (ISBE) Group
> Department of the Built Environment | Bouwkunde
> Eindhoven University of Technology, The Netherlands
> phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06
>

Re: Fuseki / ARQ DESCRIBE query to include ?s ?p

[A. Soroka]

I'm not sure what you mean by such triples as "(?s ?p  and 
probably (?s  ?o). "

Can you give some concrete examples?

---
A. Soroka
The University of Virginia Library

> On Mar 3, 2017, at 5:13 AM, Beetz, J.  wrote:
> 
> Dear community,
> 
> I have set up a Pubby http://wifo5-03.informatik.uni-mannheim.de/pubby/ 
> frontend to allow dereferencing/content-negotiation/browser-navigation of a 
> vocabulary served by Fuseki 2.4.1 .
> As per the SPARQL standard, the default behavior of DESCRIBE queries that are 
> sent by the frontend to Fuseki is left to the implementation. Fusekis default 
> behavior is to send back the graph containing all triples where  resource> is the subject ( ?p ?o). I would also like to 
> include (?s ?p  and probably (?s  ?o). 
> 
> From the list archive I have seen that I can probably implement my own 
> execDescribe() similar to this thread from some time ago: 
> http://jena.markmail.org/message/5thzze4xhqhak34g?q=describe+query+%3Fs+%3Fp+%3Fo=2#query:describe%20query%20%3Fs%20%3Fp%20%3Fo+page:2+mid:5thzze4xhqhak34g+state:results
> 
> I wonder whether there is another (easier) way through a configuration 
> setting or similar which allows me to achieve this.
> 
> Thank you very much in advance for your help
> 
> Jakob
> 
> ___
> Dr. Jakob Beetz - Assistant Professor 
> Information Systems in the Built Environment (ISBE) Group
> Department of the Built Environment | Bouwkunde
> Eindhoven University of Technology, The Netherlands
> phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06
> 

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

[anuj kumar]

I Osma,
 I briefly looked at the pull request. I beieve we need to upgrade Lucene
and Solr in one go, isnt it. The reason being Solr 4.9.1 depends on Lucene
4.9.1

Also how do i log into  issues.apache.org and where to file this bug?

Thanks,
Anuj Kumar

On Fri, Mar 3, 2017 at 11:22 AM, Osma Suominen 
wrote:

> Hi Anuj,
>
> It's great that we found agreement over this!
>
> I've restarted the Lucene upgrade effort (JENA-1250) that had stalled and
> made a PR [1] that implements the upgrade up to version 6.4.1 (with 5.5.4
> as an intermediate step). I'll wait for comments on the PR and if people
> think it's OK I will merge it soon to Jena master. Meanwhile, you can
> already base your ES implementation on that branch [2] if you like.
>
> Could you please open a JIRA issue on issues.apache.org explaining the
> Elasticsearch support feature, so that we have a place for tracking this
> work, request comments etc.
>
> Also I suggest we move the discussion around this to the developers' list (
> d...@jena.apache.org) where it's more appropriate.
>
> -Osma
>
> [1] https://github.com/apache/jena/pull/219
>
> [2] https://github.com/osma/jena/tree/jena-1250-lucene6
>
>
> 03.03.2017, 02:45, anuj kumar kirjoitti:
>
>> I second that. I am now finalising the integration of ES and should have a
>> good production quality implementation ready in a week's time.  At that
>> time I would want you guys to have a look at the implementation and
>> provide
>> feedback. Once you guys have upgraded Lucene to 6.4.1 , I can merge the
>> code in jena-text module and do a round of testing.
>>
>> Thanks,
>> Anuj Kumar
>>
>> On 2 Mar 2017 22:28, "A. Soroka"  wrote:
>>
>> I do agree that trying to juggle different versions of Lucene libraries is
>>> probably not a realistic option right now. Luckily (if I understand the
>>> conversation thus far correctly) we have a solid alternative; getting our
>>> current Lucene dependency upgraded should allow us to (eventually) merge
>>> Anuj's work into the mainstream of development. Someone please tell me
>>> if I
>>> have that wrong! :grin:
>>>
>>> Let me reiterate that this seems like very good work and speaking for
>>> myself, I certainly want to get it included into Jena. It's just a
>>> question
>>> of fitting it in correctly, which might take a bit of time.
>>>
>>> ---
>>> A. Soroka
>>> The University of Virginia Library
>>>
>>> On Mar 1, 2017, at 1:27 PM, Osma Suominen 

>>> wrote:
>>>

 Hi Anuj!

 I have nothing against modularity in general. However, I cannot see how

>>> your proposal could work in practice for the Fuseki build, due to the
>>> reasons I mentioned in my previous message (and Adam seemed to concur).
>>>

 In any case, I'll see what I can do to get the Lucene upgrade moving

>>> again. If all current Jena modules (ie jena-text and jena-spatial) were
>>> upgraded to Lucene 6.4.1, then you could just add your ES classes to
>>> jena-text, right? I think that would be better for everyone than having
>>> to
>>> maintain your own separate module.
>>>

 -Osma

 01.03.2017, 16:59, anuj kumar kirjoitti:

> I personally have no preference as to how the code in Jena should be
> structured, as long as I am able to use it :).
> I have personal preference of doing it in a specific way because IMO,
>
 it is
>>>
 modular which makes it much easier to maintain in the long run. But
>
 again
>>>
 it may not be the quickest one.
>
> I already have been given a deadline, by the company to have ES
>
 extension
>>>
 implemented in the next 15 days :). What this means is that I will be
> maintaining the ES code extension to Jena Text at-least locally for a
> coming period of time. I would be more than happy to contribute to Jena
> community whatever is required to have a proper ElasticSearch
> Implementation in place, whether within jena-text module or as a
>
 separate
>>>
 module. Till the time Lucene and Solr is not upgraded to the latest
> version, I will have to maintain a separate module for jena-text-es.
>
> Cheers!
> Anuj Kumar
>
>
> On Wed, Mar 1, 2017 at 3:36 PM, A. Soroka  wrote:
>
> Osma--
>>
>> The short answer is that yes, given the right tools you _can_ have
>> different versions of code accessible in different ways. The longer
>>
> answer
>>>
 is that it's probably not a viable alternative for Jena for this
>>
> problem,
>>>
 at least not without a lot of other change.
>>
>> You are right to point to the classloader mechanism as being at the
>>
> heart
>>>
 of this question, but I must alter your remark just slightly. From "the
>> Java classloader only sees a single, flat package/class namespace and
>>
> a set
>>>
 of compiled classes" to "ANY 

Re: Extending Jena Text to Support ElasticSearch as Indexing/Querying Engine

[Osma Suominen]

Hi Anuj,

It's great that we found agreement over this!

I've restarted the Lucene upgrade effort (JENA-1250) that had stalled 
and made a PR [1] that implements the upgrade up to version 6.4.1 (with 
5.5.4 as an intermediate step). I'll wait for comments on the PR and if 
people think it's OK I will merge it soon to Jena master. Meanwhile, you 
can already base your ES implementation on that branch [2] if you like.


Could you please open a JIRA issue on issues.apache.org explaining the 
Elasticsearch support feature, so that we have a place for tracking this 
work, request comments etc.


Also I suggest we move the discussion around this to the developers' 
list (d...@jena.apache.org) where it's more appropriate.


-Osma

[1] https://github.com/apache/jena/pull/219

[2] https://github.com/osma/jena/tree/jena-1250-lucene6

03.03.2017, 02:45, anuj kumar kirjoitti:

I second that. I am now finalising the integration of ES and should have a
good production quality implementation ready in a week's time.  At that
time I would want you guys to have a look at the implementation and provide
feedback. Once you guys have upgraded Lucene to 6.4.1 , I can merge the
code in jena-text module and do a round of testing.

Thanks,
Anuj Kumar

On 2 Mar 2017 22:28, "A. Soroka"  wrote:


I do agree that trying to juggle different versions of Lucene libraries is
probably not a realistic option right now. Luckily (if I understand the
conversation thus far correctly) we have a solid alternative; getting our
current Lucene dependency upgraded should allow us to (eventually) merge
Anuj's work into the mainstream of development. Someone please tell me if I
have that wrong! :grin:

Let me reiterate that this seems like very good work and speaking for
myself, I certainly want to get it included into Jena. It's just a question
of fitting it in correctly, which might take a bit of time.

---
A. Soroka
The University of Virginia Library


On Mar 1, 2017, at 1:27 PM, Osma Suominen 

wrote:


Hi Anuj!

I have nothing against modularity in general. However, I cannot see how

your proposal could work in practice for the Fuseki build, due to the
reasons I mentioned in my previous message (and Adam seemed to concur).


In any case, I'll see what I can do to get the Lucene upgrade moving

again. If all current Jena modules (ie jena-text and jena-spatial) were
upgraded to Lucene 6.4.1, then you could just add your ES classes to
jena-text, right? I think that would be better for everyone than having to
maintain your own separate module.


-Osma

01.03.2017, 16:59, anuj kumar kirjoitti:

I personally have no preference as to how the code in Jena should be
structured, as long as I am able to use it :).
I have personal preference of doing it in a specific way because IMO,

it is

modular which makes it much easier to maintain in the long run. But

again

it may not be the quickest one.

I already have been given a deadline, by the company to have ES

extension

implemented in the next 15 days :). What this means is that I will be
maintaining the ES code extension to Jena Text at-least locally for a
coming period of time. I would be more than happy to contribute to Jena
community whatever is required to have a proper ElasticSearch
Implementation in place, whether within jena-text module or as a

separate

module. Till the time Lucene and Solr is not upgraded to the latest
version, I will have to maintain a separate module for jena-text-es.

Cheers!
Anuj Kumar


On Wed, Mar 1, 2017 at 3:36 PM, A. Soroka  wrote:


Osma--

The short answer is that yes, given the right tools you _can_ have
different versions of code accessible in different ways. The longer

answer

is that it's probably not a viable alternative for Jena for this

problem,

at least not without a lot of other change.

You are right to point to the classloader mechanism as being at the

heart

of this question, but I must alter your remark just slightly. From "the
Java classloader only sees a single, flat package/class namespace and

a set

of compiled classes" to "ANY GIVEN Java classloader only sees a single,
flat package/class namespace and a set of compiled classes".

This is the fact that OSGi uses to make it possible to maintain strict
module boundaries (and even dynamic module relationships at run-time).

Each

OSGi bundle sees its own classloader, and the framework is responsible

for

connecting bundles up to ensure that every bundle has what it needs in

the

way of types to function, based on metadata that the bundles provide

to the

framework. It's an incredibly powerful system (I use it every day and

enjoy

it enormously) but it's also very "heavy" and requires a good deal of
investment to use. In particular, it's probably too large to put

_inside_

Jena. (I frequently put Jena inside an OSGi instance, on the other

hand.)


Java 9 Jigsaw [1] offers some possibility for strong modularization of
this kind, 

Fuseki / ARQ DESCRIBE query to include ?s ?p

[Beetz, J.]

Dear community,

I have set up a Pubby http://wifo5-03.informatik.uni-mannheim.de/pubby/ 
frontend to allow dereferencing/content-negotiation/browser-navigation of a 
vocabulary served by Fuseki 2.4.1 .
As per the SPARQL standard, the default behavior of DESCRIBE queries that are 
sent by the frontend to Fuseki is left to the implementation. Fusekis default 
behavior is to send back the graph containing all triples where  is the subject ( ?p ?o). I would also like to 
include (?s ?p  and probably (?s  ?o). 

From the list archive I have seen that I can probably implement my own 
execDescribe() similar to this thread from some time ago: 
http://jena.markmail.org/message/5thzze4xhqhak34g?q=describe+query+%3Fs+%3Fp+%3Fo=2#query:describe%20query%20%3Fs%20%3Fp%20%3Fo+page:2+mid:5thzze4xhqhak34g+state:results

I wonder whether there is another (easier) way through a configuration setting 
or similar which allows me to achieve this.

Thank you very much in advance for your help

Jakob

___
Dr. Jakob Beetz - Assistant Professor 
Information Systems in the Built Environment (ISBE) Group
Department of the Built Environment | Bouwkunde
Eindhoven University of Technology, The Netherlands
phone: +31 (0)40 247 2288 on-campus location: VRT 9.J06

Re: Wiki data

[javed khan]

Thank you Lorenz,

On Fri, Mar 3, 2017 at 10:02 AM, Lorenz B. <
buehm...@informatik.uni-leipzig.de> wrote:

> The question is strange.
>
> Wikidata provides RDF data, also accessible via SPARQL.
> DBpedia provides RDF data, also accessible via SPARQL.
>
> In addition, both provide schema information via OWL/RDFS axioms, e.g.
> domain , range, subclass hierarchy etc.
>
> Protege can load any such data.
>
> The rest should be clear: It is the same as you did for DBpedia.
>
>
>
> > Can we add wikidata in Protege like we do in DBpedia. Not sure if Protege
> > and Jena allow us to use both wikidata and DBpedia in one application.?
> >
> > On Thu, Mar 2, 2017 at 3:42 PM, Marco Neumann 
> > wrote:
> >
> >> since wikidata.org provides canonical RDF dumps the data should behave
> >> like any other data set. not particularly relevant to this list
> >> though.
> >>
> >> https://www.wikidata.org/wiki/Wikidata:Database_download#RDF_dumps
> >>
> >>
> >>
> >> On Thu, Mar 2, 2017 at 7:35 AM, javed khan 
> wrote:
> >>> Is Jena support wikidata the same way as it support DBpedia? For
> example,
> >>> we store DBpedia resources in our owl file and then access it from our
> >> Jena
> >>> code. Any example, if some one provide how to access a wikidata using
> >> Jena
> >>> code?
> >>>
> >>> Thank you.
> >>
> >>
> >> --
> >>
> >>
> >> ---
> >> Marco Neumann
> >> KONA
> >>
> --
> Lorenz Bühmann
> AKSW group, University of Leipzig
> Group: http://aksw.org - semantic web research center
>
>