I have a follow up question off of the question here:
How to get exact answers instead of the whole document using Watson Discovery?
One of the answers mentioned using the Document Conversion Service to create Possible Answer Units (PAUs) within my document. When I do this and upload this large JSON file that contains all of the PAUs, Discovery still returns the entire document that contains all of the PAUs, which I guess is expected.
To complete the solution, I assume I would have to break down each individual PAU into its own document. Does Discovery have a built in tool to do this, or do I need to write my own script?
(Ideally the script would contain some reference to the original file name/metadata and maintain the hierarchical structure that the Document Conversion Service created from my Header definitions)
Watson Discovery doesn't provide the service of giving some section of document as an answer to your query.
If you have such things in your mind, I would suggest you to use Retrieve and Rank service, which basically helps you to train watson and to get expected answer section from your provided documents.
Note: R&R service uses Document Conversion service internally
Now you can use the new passage retrieval feature to do that. It is available as "Include matching passages" in the WDS tooling or in the API reference
Passages query boolean A boolean that specifies whether the service returns a set of the most relevant passages from the documents returned by a query. The default is false.
Note: The passages parameter works only on private collections. It does not work in the Watson Discovery News collection. "
Related
I’m trying to use a REST API call to find all envelopes with subjects that are either {{cSubject_1}} OR {{cSubject_2}}.
I’m using "search_text" for filtering but I’m not sure how I should use the logical operator for “OR” for this purpose.
I would appreciate if you could help me with this.
Thanks,
Kathy
There's currently no support for this type of complex query in the search_text for The Envelopes:listStatusChanges endpoint.
The search_text allows you to have a single text item that is search across the board (recipients, subject, etc.) and is not limited to a specific meta-data. You can use other filters to filter by other means.
I would recommend storing envelope's meta-data in your application storage (or database) and using your own code to query this information if possible.
I am using ckan 2.6.0
According with the documentation: http://docs.ckan.org/en/latest/api/legacy-api.html
I am trying to use the endpoint /rest/dataset and works (only for public data but works), it only returns an array of datasets names, and nothing else, an example can be found here http://demo.ckan.org/api/1/rest/dataset
Is there a way to get a complete listing for datasets ? I also tried the search endpoint and returns the same array.
For example I would like to get the title, description, tags, file types, etc, like in the image below:
The REST api is deprecated/unmaintained and has been for a long time. Follow the up-to-date API documentation here.
package_search is your best bet: http://demo.ckan.org/api/action/package_search
That gives you a batch of datasets. Get more by paging through using the 'start' and 'rows' parameters.
If you simply want them all, then it's much better still to use a bulk download that some sites offer, such as data.gov.uk, which supplies it complete as a simple JSONL download: Meta-data for data.gov.uk datasets.
This is sort of a follow-up to someone else's question about filtering/querying a list of cars. There the recommendation for a RESTful filtering request was to put filter expressions in the query of the URI, like this:
/cars?color=blue&type=sedan&doors=4
That's fine. But what if my filtering query becomes more complicated and I need to use Boolean operators, such as:
((color=blue OR type=sedan) AND doors=4) OR color=red
That is, I want to find a four-door blue car or a four-door sedan, but if the car is red I'll take it without caring about any of the other properties.
Is there any sort of convention for providing Boolean expressions in a RESTful URI's query parameters? I suppose I could by create some new querying expression language and put it in a POST, but that seems like a heavy and proprietary approach. How are others solving this?
It is perfectly okay to use
/cars/color:blue/type:sedan/doors:4
instead of
/cars?color=blue&type=sedan&doors=4
The URL standard says only that the path should contain the hierarchical part, and the query should contain the non-hierarchical. Since this is a map-reduce, using / is perfectly valid.
In your case you need a query language to describe your filters. If I were you I would copy an already existing solution, for example the query language of a noSQL database which has a REST API.
I think resource query language is what you need. I think you could use it like this:
/sthg?q="(foo=3|foo=bar)&price=lt=10"
or forget the default queryString parser, and like this:
/sthg?(foo=3|foo=bar)&price=lt=10
I suggest you to read the manual for further details.
Since I found no other URL compatible query language (yet), I think the only other option to serialize another query language and send it in a param, like SparSQL
http://localhost:8003/v1/graphs/sparql?query=your-urlencoded-query
by marklogic7. Hydra defines a freeTextQuery in its vocab, so they follow the same approach. But I'll ask Markus about this. It's a complicated topic, since according to the self-descriptive messages constraint you should describe somewhere what type of query language you use in the URL. I am not sure about this. :S
conclusion:
In order to support ad-hoc search queries we need a standard way to describe them in the link meta-data. Currently there are only a few standards about this. The most widely used standard is URI templates which does not support nested statements, operators, etc... for what I know. There is a draft called link descriptions which tries to fill the gap, but it is incomplete.
One possible workaround to define an URI template with a single q parameter which has rdf:type of x:SearchQuery and rdfs:range of xsd:string, and create another vocab about how to describe such a x:SearchQuery. After that the description could be used to build search forms, and validate queries sent to the server. Already existing queries could be supported too with this approach, so we don't need a new one.
So this problem can be solved with vocabs or new URI template standards.
I have seen many use a query string as you have provided - much like a SQL query string.
Here are just two examples:
Socrata (Open Data Portal company)'s SoQL (SQL variant): http://dev.socrata.com/consumers/cookbooks/querying-block-ranges.html
openFDA (API from fda.gov for open data) uses a similar string-based query parameter which maps to ElasticSearch queries, I believe: https://open.fda.gov/api/reference/#query-syntax
Try using 1 for true, 0 for false.
/_api/web/lists/getbytitle('XYZ')/items?$filter=Active eq 1
I'm designing a RESTful API and I'm asking myself question about the filter field.
On my gets queries I want the user to be able to select the fields he want to get in the response. I was pretty sure that it would be the field filter jobs to give me the requested field but, after some reshearch, I found that most of the time it's used to add criteria on the fields, as a IF. Is it the user that needs to make show or hide the fields ans the Api return the full ressource everytime ?
I got an other question which is about the URI representation of such filter. Should it be something like /foo?fields=[bar1,bar2] ?
Thanks
It's not common to have a resource where you can specify what fields you want returned, by default all fields will get returned. If your resource has a lot of fields or some fields have really big values, it can be a good idea to have a way to specify which fields you want returned.
In REST there are no strict rules about how you should design your URLs for filters. It is indeed common to use GET parameters because they can be optional and don't have to be in any specific order. Your proposal of /foo?fields=[bar1,bar2] seems fine, however i would personally leave off the brackets.
Google Compute Engine API uses the 'fields' request parameter (see the documentation). The syntax is flexible enough to let user select/restrict even the nested elements. You may find it useful.
Yoga is a framework that allows you to deploy your own REST API's with selectable fields. This can reduce roundtrips to the server, and improve performance.
Right now I am working on a project to fetch data from a SharePoint list using SOAP API. I tried and successfully fetches the complete list, but now I want to fetch some specific data that is updated after a specific date.
Is this possible to fetch such data using SOAP query. I can see last update filed when I view single item at the bottom. Is this some how possible to use that filed?
Yes you can use the Web Services to do lot of things just like filtering a list result. I don't know which language you use, but with JavaScript you can look at these two frameworks that should help you:
http://aymkdn.github.io/SharepointPlus/ : easy way to create your queries (I created it)
http://spservices.codeplex.com/ : the most popular framework but less easy to use (it's my point of view)
You can also look at the documentation on MSDN (the param to use is query): http://msdn.microsoft.com/en-us/library/lists.lists.getlistitems.aspx
At last found the answer,
The last update date and time can be retrieved from the list column "Modified".
The soap response will have the value in the attribute "ows_Modified".
Muhammad Usman