I'm using ConceptNet http://conceptnet.io to try to get related keywords using both their relatedto and edge/query endpoints. The data is awesome, however I've encountered some behaviour I can't figure out.
If you query "relatedto" for the keyword "person" with a limit of 20 on the main site you get:
http://conceptnet.io/c/en/person?rel=/r/RelatedTo&limit=20
Or this list of words:
doll
character
statue
person
servant
body
farmer
child
man
baby
guard
name
doctor
captain
people
neighbour
boy
Pretty awesome right? That's super topical and useful.
On the other hand if you query the API with what appears to be the same query formatted for the API:
http://api.conceptnet.io/related/c/en/person?filter=/c/en&limit=20
Shortened for clarity (see the link above for the full response):
{
"#id": "/c/en/person",
"related": [
{
"#id": "/c/en/person",
"weight": 1.0
},
{
"#id": "/c/en/sean_connery",
"weight": 0.963
},
{
"#id": "/c/en/steve_ballmer",
"weight": 0.962
},
{
"#id": "/c/en/norman_jewison",
"weight": 0.962
},
{
"#id": "/c/en/aretha_franklin",
"weight": 0.962
}
]
}
Huh. What happened there? That's a lot less useful. We got just names and not very related terms.
So my question is: How do I get a similar list?
Are they using some complex edge analysis (using a standard, not relatedto query) to get the relatedterms on the website?
OR
Am I missing something I can't figure out?
Any help much appreciated.
Thanks
To query for existing edges labeled with /r/RelatedTo that contain the node /c/en/person, you should query: http://api.conceptnet.io/query?node=/c/en/person&rel=/r/RelatedTo
The results of that query match the Web site.
The /related endpoint is different, and is only present in the API. It applies some machine learning to predict nodes that are related, whether or not the edge connecting them is already present in ConceptNet. It's better for more specific concepts than "person". Try "teacher" for example: http://api.conceptnet.io/related/c/en/teacher?filter=/c/en&limit=20
Related
Many thanks for looking at this for me.
I am working in IBM ACE V11 software and in my service, I receive a JSON message.
I need to map this JSON message to a SOAP request via ESQL.
Please see the sample message below:
Incoming JSON message:
"journals": [
{
"journalName": "Plant Species in London",
"journalYear": "2016",
"journalAuthor": [
{
"name": "Julian Bose",
"subject": "botany"
}
{
"name": "Samantha Adams",
"subject": "biology"
},
],
"samplePolling": {
"pollingInterval": 120,
"totalAttempts": 10
}
},
],
"supervisorName": "James Smith"
}
In ESQL I have so far:
For Journal's Name:
SET OutputRoot.SOAP.Body.ns:submitJournal.ns:journalName = InputRoot.JSON.Data.journals.journalName;
For Journal's Year:
SET OutputRoot.SOAP.Body.ns:submitJournal.ns:journalYear = InputRoot.JSON.Data.journals.journalYear;
For Journal's Author, I have a problem. The problem is that there can be 0 to 3 or more authors.
In this case, there are 2 authors.
How do I first check if any authors are present and if so, how many are there and then how to assign each authors' details to SOAP. (All of this in ESQL).
In ESQL I have this so far. But I don't know how to get the "n" value. (n represents no. of authors).
SET OutputRoot.SOAP.Body.ns:submitJournal.ns:journalAuthorValues[n].ns16:AuthorName = InputRoot.JSON.journals.journalAuthor[n].name;
Any and all help is greatly appreciated.
For Journal's Author, I have a problem. The problem is that there can be 0 to 3 or more authors. In this case, there are 2 authors.
You need to iterate over the array of authors, and you are assuming that you need to count the number of authors. But you do not need to. This should work just fine (not tested, may contain syntax errors)
FOR refAuthor AS InputRoot.JSON.Data.journals.(JSON.Array)journalAuthor[] DO
CREATE LASTCHILD OF OutputRoot.SOAP.Body.ns:submitJournal.ns:journalAuthorValues
TYPE NAMEVALUE
IDENTITY ns16:AuthorName
VALUE FIELDVALUE(refAuthor);
END FOR
You should try to avoid using counted loops in ESQL. A FOR statement or a SELECT statement is almost always simpler and better.
I'm using couchdb to store large documents, which is causing some trouble when fetching them to memory. I do realize the database is not meant to be used this way. As a fallback solution, is it possible to fetch partial documents from the database, without creating a view?
In example, if a document has the fields id, content and extra_content, I would like to retrieve only the first two.
Thank you in advance.
If you are using CouchDB 2.x, you can use /db/_find endpoint as a mechanism to retrieve part of the doc.
POST /db/_find
{
"selector": {
"_id": "a-doc-id"
},
"fields": [
"_id",
"content"
]
}
You'll get only the set of fields you have specified in the query
This is not possible prior to CouchDB 2.x. For CouchDB 2.x or greater, see JuanjoRodriguez's answer.
But one possible work around for any version of CouchDB would be to take advantage of file attachments, which by default are excluded from a fetch. If some of your data isn't always needed, and doesn't need to be included in indexes, you could potentially store it as (JSON) attachments, rather than as part of the document directly:
{
"id": "foo",
"content": "stuff",
"extra_content": "other stuff"
}
becomes:
{
"id": "foo",
"content": "stuff",
"_attachments": {
"extra_content": {
"content_type": "application/json",
"data": "ZXh0cmEgc3R1ZmYK"
}
}
}
Below I have environment file and recipe can you explain I am not getting what is the list here.
{
"json_class": "Chef::Environment",
"description": "prod environment",
"default_attributes": {
},
"chef_type": "environment",
"override_attributes": {
"user": {
"mapr": {
"id": "application",
"group": "application",
},
"local" : {
"id": "chef",
"group": "chef"
},
"ldap" : {
"id": "ldap",
"sudo": true,
},
}
"name": "prod"
}
Below is the recipe what is the list here i did not get
node['user_create'].each do |list, user|
group user['group'] do
group_name user['group']
gid user['gid']
action [:create]
ignore_failure true
end
user user do
username user['id']
uid user['uid']
group user['gid']
home user['home']
manage_home true
end
if list !='ldap'
How list is passing here in if condition
You are not actually passing in any attributes via the environment, which you can see because the values of default_attributes and override_attributes are both just empty hashes { }. The data you've included there is just ignored by Chef as noise. In the future I recommend you use the Ruby DSL for environment files as it has more error checking for things like this (though not perfect error checking).
As an aside, you've been asking a lot of questions on here and seem to be struggling with Chef. Please consider joining the Chef community Slack team and asking there instead as it's a full chat system and thus the community could offer real-time help rather than here random blurbs.
In my instance of Solr 4.10.3 I would like to index JSONs with a nested structure.
Example:
{
"id": "myDoc",
"title": "myTitle"
"nestedDoc": {
"name": "test name"
"nestedAttribute": {
"attr1": "attr1Val"
}
}
}
I am able to store it correctly through the admin interface:
/solr/#/mySchema/documents
and I'm also able to search and retrieve the document.
The problem I'm facing is that when I get the response document from my Solr search, I cannot see the nested attributes. I only see:
{
"id": "myDoc",
"title": "myTitle"
}
Is there a way to include ALL the nested fields in the returned documents?
I tried with : "fl=[child parentFilter=title:myTitle]" but it's not working (ChildDocTransformerFactory from:https://cwiki.apache.org/confluence/display/solr/Transforming+Result+Documents). Is that the right way to do it or is there any other way?
I'm using: Solr 4.10.3!!!!!!
To get returned all the nested structure, you indeed need to use ChildDocTransformerFactor. However, you first need to properly index your documents.
If you just passed your structure as it is, Solr will index them as separate documents and won't know that they're actually connected. If you want to be able to correctly query nested documents, you'll have to pre-process your data structure as described in this post or try using (modifying as needed) a pre-processing script. Unfortunately, including the latest Solr 6.0, there's no nice and smooth solution on indexing and returning nested document structures, so everything is done through "workarounds".
Particularly in your case, you'll need to transform your document structure into this:
{
"type": "parentDoc",
"id": "myDoc",
"title": "myTitle"
"_childDocuments_": [
{
"type": "nestedDoc",
"name": "test name",
"_childDocuments_" :[
{
"type": "nestedAttribute"
"attr1": "attr1Val"
}]
}]
}
Then, the following ChildDocTransformerFactor query will return you all subdocuments (btw, although it says it's available since Solr 4.9, I've actually only seen it in Solr 5.3... so you need to test):
q=title:myTitle&fl=*,[child parentFilter=type:parentDoc limit=50]
Note, although it returns all nested documents, the returned document structure will be flattend (alas!), i.e., you'll get:
{
"type": "parentDoc",
"id": "myDoc",
"title": "myTitle"
"_childDocuments_": [
{
"type": "nestedDoc",
"name": "test name"
},
{
"type": "nestedAttribute"
"attr1": "attr1Val"
}]
}
Probably, not really what you've expected but... this is the unfortunate Solr's behavior that will be fixed in a nearest future release.
You can put
q={!parent which=}
and in fl field :"fl=*,[child parentFilter=title:myTitle].
It will give you all parent field and children field of title:mytitle
I am using #RepositoryRestResource annotation to expose Spring JPA Data as restful service. It works great. However I am struggling with referencing specific entity within angular app.
As known, Spring Data Rest doesn't serialise #Id of the entity, but HAL response contains links to entities (_links.self, _embedded.projects[]._links.self) like in the following example:
{
"_links": {
"self": {
"href": "http://localhost:8080/api/projects{?page,size,sort}",
"templated": true
}
},
"_embedded": {
"projects": [
{
"name": "Sample Project",
"description": "lorem ipsum",
"_links": {
"self": {
"href": "http://localhost:8080/api/projects/1f888ada-2c90-48bc-abbe-762d27842124"
}
}
},
...
My Angular application requires to put kind of reference to specific project entity in the URL, like http://localhost/angular-app/#/projects/{id}. I don't think using href is good idea. UUID (#Id) seems to be better but is not explicitly listed as a field. This is point I got stuck. After reading tons of articles I came up with 2 ideas, but I don't consider neither of those as a perfect one:
Idea 1:
Enable explicitly serialisation of #Id field and just use it to reference to the object.
Caveat: exposing database specific innards to front-end.
Idea 2:
Keep #Id field internal and create an extra "business identifier" field which can be used to identify specific object.
Caveat: Extra field in table (wasting space).
I would appreciate your comment on this. Maybe I am just unnecessarily too reserved to implement either of presented ideas, maybe there is a better one.
To give you another option, there is a special wrapper for Angular+Spring Data Rest that could probably help you out:
https://github.com/guylabs/angular-spring-data-rest