I want to retrieve the DOI for a combination of a title, the first author, and the year. I wanted to use the query method, but there is no date or year filed in it. It also does not allow me to use a title. Here is the example article I want to get its DOI:
title: "The generic name Mediocris (Cetacea: Delphinoidea: Kentriodontidae),
belongs to a foraminiferan"
author : Mark D Uhen
Year: 2006
I tried this but it failed (although I could not find any filed name for the year):
last_name='Uhen'
title = 'The generic nameMediocris (Cetacea: Delphinoidea: Kentriodontidae), belongs to a foraminiferan'
q = works.query(author=last_name, title = title)
Here is the error I got:
UrlSyntaxError: Field query title specified but there is no such field query for this route. Valid field queries for this route are: affiliation, author, bibliographic, chair, container_title, contributor, editor, event_acronym, event_location, event_name, event_sponsor, event_theme, funder_name, publisher_location, publisher_name, translator
I appreciate any help!
Thanks
In the browser, the link would be:
https://api.crossref.org/works?query.author=Uhen&query.bibliographic=The%20generic%20name&filter=from-pub-date:2006-01-01,until-pub-date:2006-12-31
(I don't know what software you are using, but it might be one step towards a solution to change the field name title to bibliographic)
Related
search = request.form.get("search")
book = db.execute("SELECT * FROM books WHERE title = :search OR author = :search OR isbn = :search OR title LIKE :search",{"search": search}).fetchall()
This is a portion of my function. I want the user to be able to search for a book and store their result in "search", and I want to be able to pull any results from the database list that at least has the "search" even if the title isn't complete. Example, if the user is looking for a book titled "the fisherman" but the user only types in "the fisher" I want the query to be able to pull "the fisherman".
book = db.execute(text("SELECT * FROM books WHERE title LIKE :search"),
{"search": f"%{search}%"}).fetchall()
The error was in my dictionary. To have a variable that the user inputs to be looked up using '% %' must be modified within the dictionary.
I am facing Data Category visibility related issue.
The scenario is i'm following -
I have One Community User which one is using for login into my community.
This User's role is Inheriting Visibility for Category Group from it's parant role and it's Visibility is No categories are visible to parent role and subordinates.
But This User's Permission set have Custom Visibility Permission is like -
All Category Group > child Category > sub child Category
for ex :
All Products > Computers > Laptops
And I am accessing lick bellow query from apex to display related article in community.
Select Id, Title, KnowledgeArticleId, Summary, CreatedDate, UrlName From KnowledgeArticleVersion WHERE Language = 'en_US' and PublishStatus='Online' WITH DATA CATEGORY Products at (Computers__c) limit 10 UPDATE VIEWSTAT
but I am not getting any articles.
getting error like --
Invalid data category name provided: Products. There is no data category matching the given developer name on the data category group: Computers__c
If anyone have solution for this please let me know.
Thank you,
Harsiddhi.
You probably have already figured this out by now, however you need to use the API name for your Group as well, i.e. 'Products' becomes 'Products__c'.
Should be something more like this:
Select Id, Title, KnowledgeArticleId, Summary, CreatedDate, UrlName From KnowledgeArticleVersion WHERE Language = 'en_US' and PublishStatus='Online' WITH DATA CATEGORY Products__c at (Computers__c)
Queries are not dependent on permission sets.
The error in the SOQL query can be looked upon at the query editor. Whenever there is a wrong API name in the query, there comes down an indication in the Query Editor under Developer Console that:
No such column 'field_name' on entity
Thus we can look back at the object fields and relationships and can ensure if the right API name is there.
As you know when using the listdata.svc people picker fields return the userID, not the display name (createdby, modifiedby). I have been looking for a way to query the userprofile svc but have found nothing helpful.
What i am looking to do, is simply convert this ID to their respected display name. I am new to using this listsvc and this was never and issue using empty data views and XSL. If anyone has an example of grabbing list data, and showing the createdby, modifiedby, or a custom people picker field and showing their name not id that would be very helpful.
Thanks in advance
This is a default behavior, for a user field, only Id property is getting returned in the result. To return all the properties of user field $expand query options needs to be applied to the query, for example:
/_vti_bin/ListData.svc/Documents?$expand=CreatedBy,ModifiedBy
In that case the projected field values for CreatedByand ModifiedBy fields (from User Information List) are returned along with the result.
To return a specific user field properties, the $select query option could be specified. For example, the following query returns DisplayName (Title property) of CreatedBy and ModifiedBy fields:
/_vti_bin/ListData.svc/Documents?$select=CreatedBy/Title,ModifiedBy/Title&$expand=CreatedBy,ModifiedBy
Where can I find a reference of the Cayley database format? I find it confusing.
For example in the demo database of movie info, why do so many values start with "/en"?
Why does the following row have '/film' twice and why is there a dot at the end?
":/en/the_window" "/film/film/starring" ":53570" .
Why does Stephen Fry appear so many times?
The example cayley's database of movies is part of Freebase, so is using the freebase name convention.
The id property follow the rule:
/en - top level namespace for all human readable IDs
In the case of film/film/starring the first film is a common domain, the second one is the object and the third one is the name of the property.
You can read more at the page namespace in freebase wiki
The title is a bit awkward but I couldn't found a better one. My problem is as follows:
I have several users stored as documents and I am storing several key-value-pairs or items (which have an id) for each document. Now, if I apply highlighting with hl.snippets=5 I can get the first 5 items. But every user could have several hundreds items, so
you will not get the most relevant 5 items. You will get the first 5 items ...
Another problem is that
the highlighted text won't contain the id and so retrieving additional information of the highlighted item text is ugly.
Example where items are emails:
user1 has item1 { text:"developers developers developers", id:1, title:"ms" }
item2 { text:"c# development", id:2, title:"nice!" }
...
item77 ...
user2 has item1 { text:"nice restaurant", id:3, title:"bla"}
item2 { text:"best cafe", id:4, title:"blup"}
...
item223 ...
Now if I use highlighting for the text field and query against "restaurant" I get user2 and the text nice <b>restaurant</b>. But how can I determine the id of the highlighted text to display e.g. the title of this item? And what happens if more relevant items are listed at the end of the item-list? Highlighting won't display those ...
So how can I find the best items of a documents with multiple such items?
I added my two findings as answers, but as I will point out each of them has its own drawbacks.
Could anyone point me to a better solution?
One of my rules of thumb for designing Solr schemas is: the document is what you will search for.
If you want to search for 'items', then these 'items' are your documents. How you store other stuff, like 'users', is secondary. So 'users' could be in another index like you mentioned, they could be "denormalized" (e.g. their information duplicated in each document), in a relational database, etc. depending on RDBMS availability, how many 'users' there are, how many fields these 'users' have, etc.
EDIT: now you explain that the 'items' are emails, and a possible search is 'restaurant X' and you want to find the best 'items' (emails). Therefore, the document is the email. The schema could be as simple as this: (id, title, text, user).
You could enable highlighting to get snippets of the 'text' or 'title' fields matching the 'restaurant X' query.
If you want to give the end-user information about the users that wrote about 'restaurant X', you could facet the 'user' field. Then the end-user would see that John wrote 10 emails about 'restaurant X' and Robert wrote 6. The end-user thinks "This John dude must know a lot about this restaurant" so he drills down into a search by 'restaurant x' with a filter query user:John
You could use use two indices: users->items as described in the question and an index with 'pure items' referencing back to the user.
Then you will need 2 queries (thats the reason I called the question '2d Search in Solr'):
query the user index => list of e.g. 10 users
query the items index for each user of the 1. step => best items
Assume the following example:
userA emails are "restaurant X is bad but restaurant X is cheap", "different topic", "different topicB" and
userB emails are "restaurant X is not nice", "revisited restaurant X and it was ok now", "again in restaurant X and I think it is the best".
Now I query the user index for "restaurant X" and the first user will be userB, which is what I want. If I would query only the item-index I would get the item1 of less relevant userA.
Drawbacks:
bad performance, because you will need one query against the user index and e.g. 10 more to get the most relevant items for each user.
maintaining two indices.
Update to avoid many queries I will try the following: using the user index to get some highlighted snippets and then offering a 'get relevant items'-button for every user which then triggers a query against the item index.
You can use the collapse patch and store each item as separate document linking back to the user.
The problem of that approach is that you won't get the most relevant user. Ie. the most relevant item is not necessarily from the most relevant user (because he can have several slightly less relevant items)
See the "Assume the following example:" part in my second answer.