Hi Florent, all Now there are around 30 integration tests for the /query and /find endpoint. 20 of them are more or less tests that check correct error handling / default values and the validity of returned data. The others are tests similar to the examples also used in the documentation. I have also written some utility classes that make it more convenient to add additional one. So feel free to add your own.
Tomorrow I will start to work on the integration tests for the other services of the Entityhub best Rupert Westenthaler ---------- Forwarded message ---------- From: Florent André <[email protected]> Date: Tue, Jul 26, 2011 at 12:13 AM Subject: Re: entityhub/query endpoint not still running ? To: [email protected] OK ! I got it ! I fact, I used endpoint : - entityhub/query without the *sites* sub-resource (entityhub/sites/query). With *sites* sub-resource it works well. And in fact, _without_ sites what I see is : - entityhub/query : send empty results - entityhub/find : send 404. In documentation entityhub/query is mark as local managed entities... DBpedia import is in local right ? So I may have results for this request... or I get wrong somewhere ? I update integration tests with /sites/. I just actually test 2 requests [1], and it will be cool to integrate your documentation's query. Do you have a pointer in mind ? Thanks ! [1] https://svn.apache.org/repos/asf/incubator/stanbol/trunk/integration-tests/src/test/java/org/apache/stanbol/entityhub/it/EntityHubTest.java On 07/25/2011 11:16 PM, Rupert Westenthaler wrote: > > Hi > > On Mon, Jul 25, 2011 at 7:52 PM, Florent André<[email protected]> wrote: >> >> Rupert, >> >> Thanks for your answer. >> >> I have made modifications to my requests following your advice (I hope >> well), but I don't still get results. >> > Do you query against the dbpedia.org dataset? > If so, could you please post the queries you have problems with. > >> I order to automat (and train myself) I wrote a first little integration >> test for entityhub. >> For now it's only test value and text query on entityhub/query endpoint. >> > While working on STANBOL-298 I made several test queries - for the > documentation - this queries would be also nice to use for unit tests. > In order to test such queries I also included additional fields > (geo:lat, geo:long, geo:alt, dbpedia-ont:totalPopulation ...) in the > default data index. This index would than also allow to test most of > the features of the field query against the default dataset. > >> I also add a test on /symbol endpoint, even if it's seems me to remember >> that it's outdated... but it's still in documentation. >> > the /symbol endpoint is no longer around but was moved to /entity > about a month ago. So if you still have a /symbol than you should > check if you run the current version. > >> For now, this integration test pass on wrong value because I don't want to >> break the build for this... but when problem solved I will manage accurate >> tests. >> > Thx for starting this. > > best > Rupert > >> Cheers. >> >> >> On 07/25/2011 06:34 AM, Rupert Westenthaler wrote: >>> >>> Hi >>> >>> On Sat, Jul 23, 2011 at 8:37 PM, florent andré >>> <[email protected]> wrote: >>>> >>>> Hi Rupert, all >>>> >>>> I just update stanbol to the last version and I figure out that >>>> entityhub/query don't answer to my previously running requests. >>>> Do this endpoint don't still like me ? :) >>>> >>>> So I run the full launcher, and restart from the online documentation (in >>>> entityhub enpoint / rest api ) and try examples. >>>> >>>> so I, for example : >>>> ------- >>>> $ curl -X POST -H "Content-Type:application/json" --data >>>> "@fieldQueryjson" >>>> http://localhost:8080/entityhub/query >>>> ------- >>>> >>>> Where >>>> -------- >>>> @fieldQueryjson >>>> { >>>> "selected": [ >>>> "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label", >>>> "http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#type"], >>>> "offset": "0", >>>> "limit": "3", >>>> "constraints": [ >>>> { >>>> "type": "value", >>>> "field": "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label", >>>> "value": "Paris", >>>> } >>>> >>>> ] >>>> } >>>> --------- >>>> >>>> Answer : >>>> --------- >>>> { >>>> "query": { >>>> "selected": [ >>>> "http:\/\/www.w3.org\/1999\/02\/22-rdf-syntax-ns#type", >>>> "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label" >>>> ], >>>> "constraints": [{ >>>> "type": "value", >>>> "value": "Paris", >>>> "field": "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label" >>>> }], >>>> "limit": 3 >>>> }, >>>> "results": [] >>>> ---------- >>>> >>> >>> This result is expected for the DBPedia dataset because value >>> constraints do map parsed values to the data type "xsd:String" however >>> the Entityhub uses "entityhub:text" for natural language values. I >>> will update the example of the online help to use a more typical >>> example. I will also add a list of supported data types. >>> >>> The get the results expected results you would need to use the >>> following constraint >>> >>> "constraints": [{ >>> "type": "value", >>> "value": "Paris", >>> "field": "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label", >>> "dataTypes": >>> ["http://www.iks-project.eu/ontology/rick/model/text";] >>> }], >>> >>> In addition I will implement support for "prefix:localname" so that it >>> is possible to use "entityhub:text" instead of the full URL >>> >>>> Others examples do the same. >>>> >>>> Do I miss something ? >>>> >>>> Another point : >>>> >>>> I see that for constraints type:text, the field patternType is now >>>> mandatory... even if documentation says that default value is to "none" >>>> and >>>> in previous version we can miss this property without problems. >>>> >>>> When no pattern type is in the request, message is : >>>> Constraint parsing Errors: >>>> >>>> Illegal value for field 'patternType'. >>>> Supported values are: [none, regex, wildcard] >>>> Parsed Constraint: >>>> { >>>> "type": "text", >>>> "languages": ["de"], >>>> "text": "Frankf*", >>>> "field": "http:\/\/www.w3.org\/2000\/01\/rdf-schema#label" >>>> } >>>> >>> >>> The reason for that is that "JSONObject.optString("patternType") now >>> returns an empty string if the property is not present. However the >>> code expects NULL to be returned in such cases. >>> >>> Because opt***(...) methods are used on several places in different >>> places I will need to review all such use ages. >>> >>> I hope I can provide a patch for this later today. In the meantime >>> please parse a valid patternType. >>> >>> BTW: >>> >>>> "text": "Frankf*", >>> >>> will not return any values for pattern type 'none' >>> >>> >>>> Thanks >>>> ++ >>>> >>> >>> Thanks for the report! >>> >>> best >>> Rupert Westenthaler >>> >>> >> > > > -- | Rupert Westenthaler [email protected] | Bodenlehenstraße 11 ++43-699-11108907 | A-5500 Bischofshofen
