When trying to query for a specific DOI attribute using the following URL:
https://api.labs.cognitive.microsoft.com/academic/v1.0/evaluate?model=latest&count=10&offset=0&attributes=Id,Ti&expr=And(Composite(DOI='doi:10.1594/PANGAEA.667386'),Y=[2000,2009])&subscription-key=SUBSCRIPTION_KEY_HERE
I get the following error:
{"Error":{"Code":"Bad Argument","Message":"Invalid query expression\r\nParameter name: expression"}}
However when accessing using a different attribute, e.g. journal ID as below:
https://api.labs.cognitive.microsoft.com/academic/v1.0/evaluate?expr=And(Composite(J.JId=114840262),Y=[2013,2015])&model=latest&count=10&offset=0&attributes=Id,Ti,J.JN,J.JId,Y&subscription-key=SUBSCRIPTION_KEY_HERE
It works fine! Why does the behaviour of the API only work with some attributes? What am I doing wrong?
Relevant documentation I've read:
https://learn.microsoft.com/en-us/azure/cognitive-services/academic-knowledge/evaluatemethod
https://learn.microsoft.com/en-us/azure/cognitive-services/academic-knowledge/queryexpressionsyntax
Not all entity attributes can be queried for/matched against; some can only be requested as part of the result when querying against other entity attribute fields.
You can reference the Paper Entity documentation to see what query operations are available for different attributes. For example citation count (CC) does not support any matching operations, hence the "none" in the "Operations" column, however journal name (J.JN) supports the equality operator.
Unfortunately, DOI is part of the "Extended" attributes, none of which support matching operations.
Related
We have an index set up in Azure cognitive search that has two string fields (hash1 & hash2) containing separate hashes. We would like to query the index for documents where the two hashes within a document aren't equal.
I tried applying the filter: $filter=hash1 ne hash2, expecting the query to return all documents with mismatched hashes. Instead, I was greeted with the following error message:
"Invalid expression: Comparison must be between a field, range variable or function call and a literal value.\r\nParameter name: $filter"
From what I can gather there seems to be some kind of limitation preventing comparisons between fields. Would it be possible to perform this type of query in Azure cognitive search using a different technique?
I would use content enrichment in this case. Even if comparing two hashes with a query was supported, it would be inefficient compared to pre-calculating the value using a content enrichment technique.
Introduce a new boolean property called something like HasEqualHashes
Populate that property with an appropriate boolean value
Use a $filter to filter your content as you wish
search=whatever&$filter=HasEqualHashes
Note that two different scenarios determine how you can enrich your content.
CONTENT SUBMITTED VIA SDK
When you use the SDK to submit content, you can enrich your items any way you want using regular code. Populating your HasEqualHashes property is a trivial one-liner in C#.
CONTENT SUBMITTED USING BUILT-IN INDEXERS
If you use one of the built-in indexers, you have to learn and understand the concept of skillsets.
https://learn.microsoft.com/en-us/azure/search/cognitive-search-working-with-skillsets
In reference material for CouchDB and Couchbase it's common guidance to store the type of a document as a parameter within the actual document.
I've got a database, where I have different documents that record certain behaviour by URL. So naturally, I use the URL as the id of the document.
The problem I find is that by using just the key as the document id, I now get clashes between documents of different types. So I have started using the type as the first part of the key like this:
{ doc._id: "rss_entry|http://www.spiegel.de/1234", [...] }
{ doc._id: "page_text|http://www.spiegel.de/1234", [...] }
Now I start to wonder why I've never seen this approach to model type in any of the documentation.
Prefixes are commonly used. In addition to support for scenarios such as yours, prefixing allows one to perform logical range queries against views. There is use of this technique in the modeling examples, but perhaps the concept is not described in as much detail as you are expecting. In the section http://docs.couchbase.com/couchbase-devguide-2.5/#modeling-documents, the documents are keyed as beer_NNNN and brewery_NNNN. Also, the section http://docs.couchbase.com/couchbase-devguide-2.5/#using-reference-documents-for-lookups goes a bit deeper into this technique. There is a counter document named user::count and then each user is keyed as user::NNNN. Additionally, there are documents in the example that are keyed as fb::NNNN for a Facebook ID, email::XXX#YYYY.com for a user's email address, etc.
We added the department number from AD to sharepoint. This property is multi valued in AD, and its multivalue in sharepoint.
My user profile screenshot:
http://screencast.com/t/e9xaZMyJJ2
Then in the CSWP, I want to filter by this value, please check here:
http://screencast.com/t/rlP95vrYRB3E
If I check the TEST, its using a GUID instead of the 613 code
http://screencast.com/t/ASltLUsIP
I am totally clueless.!! any idea?
Mapped property screenshot here:
http://screencast.com/t/gLXs2ZIR
In your user profile the department number is stored as a 'term' using a managed metadata field.
It's important to know that a 'term' can be translated or you can even define synonyms.
When using managed metadata in search, search will use the id (=a guid) of the term instead of the actual text ('613').
Since it ignores the text (and uses the id of the term), this makes it possible for search to find your term in any language or synonyms.
In your case translation of '613' is not really applicable but imagine that your department was a text instead of a number.
When searching on the term 'HR', search could return all the items with 'HR' but also the ones with 'personeelsdienst' (HR in Dutch).
So far I haven't found any samples of HOW the elastic.js client api (https://github.com/fullscale/elastic.js) can be used for indexing documents. There are some clues here & there but nothing concrete yet.
http://docs.fullscale.co/elasticjs/ejs.Document.html
Document ( index, type, id ): Object used to create, replace, update, and delete documents
Document > doIndex(fnCallBack): Stores a document in the given index and type. If no id is set, one is created during indexing.
Document > source (doc): Sets the source document.
Can anyone provide a sample snippet of code to show how an document object can be instantiated and used to index data?
Thanks!
Update # 1 (Sun Apr 21st, 2013 on 12:58pm CDT)
https://gist.github.com/pulkitsinghal/5430444
Your gist is correct.
You create ejs.Document objects specifying the index, type, and optionally the id of the document you want indexed. If you don't specify an id, elasticsearch will generate one for you.
You set the source to the json object you want indexed then call the doIndex method specifying a callback if needed. The node example does not index docs, but the angular and jquery examples show a basic example and can easily be used with the node client.
https://github.com/fullscale/elastic.js/blob/master/examples/angular/js/controllers.js#L30
Also have a peek at the tests:
https://github.com/fullscale/elastic.js/blob/master/tests/index_test.js#L265
elastic.js nowadays only implements the Query DSL, so it can't be used for this scenario anymore. See this commit.
I have some problems with CMIS query language. I want to get all documents (table no important), which have some property. So I wrote Select my_property from cmis:document.
Unfortunately I get answer: 0 documents. But when I alter query to Select my_property from my_table. I get different answer.
Could you tell me why?
The reason is that the spec does not provide for it. Here is what the spec says about the "relational view projection" (source):
In each Virtual Table, a Virtual Column is implicitly defined for each
property defined in the Object-Type Definition AND for all properties
defined on ANY ancestor-type of the Object-Type but NOT defined in the
Object-Type definition.
So a given object-type can be queried for properties of ancestor types, but the spec makes no provision for querying an object-type for properties of descendent types, which is what you are trying to do.
Jeff