-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add new output
field to features
#130
Comments
If I understand this correctly it seems to be very much like our data extension functionality. I think that clients who want to get more information about candidates (for custom scoring etc.) could do so by using a data extension request based on the candidate IDs like this (following your example): {
"ids": [
"12345"
],
"properties": [
{"id": "P361"},
{"id": "P138"}
]
} And get back something like: {
"meta": [
{
"id": "P361",
"name": "part of"
},{
"id": "P138",
"name": "named after"
}
],
"rows": [
{
"id": "12345",
"properties": [
{
"id": "P361",
"values": [
{"str": "[San Francisco Bay Area](https://www.wikidata.org/wiki/Q213205)"},
{"str": "[San Francisco–San Mateo–Redwood City metropolitan division](https://www.wikidata.org/wiki/Q63567254)"}
]
},{
"id": "P138",
"values": [
{"str": "[Francis of Assisi](https://www.wikidata.org/wiki/Q676555)"}
]
}
]
}
]
} So it seems to me that we don't need additional functionality in the protocol to do this. |
Hmm but the domain is what I was also highlighting as a need. If I use the data extension, how would one extend for a set of properties that define a domain or in a namespace to return to a client? In my example I only want location properties. |
Right, I missed that part in your example. Perhaps this could be done using property proposals, so something like this:
Would return this: {
"type": "location",
"properties": [
{
"id": "P361",
"name": "part of"
}, {
"id": "P138",
"name": "named after"
}
]
} Which could then be used by clients to create the data extension query from above. |
@fsteeg Nice, yeah, I can see |
We added #31 to give some control over candidate scoring to clients, but its not full control or enough as sort of asked for in a few issues and #61
Clients might simply want to provide some constraints or limitations in a query, which is being discussed in #23 and #88 and elsewhere.
But in #61 and in #128 there opens a need to perhaps also allow asking a service to output or return much more information about each candidate entity that might match some constraints or limitations.
In Freebase days there was a way to request additional information or output from the service.
Example:
Match "san francisco" and return all data in the location domain about it that is accessible via the output parameter.
For reconciliation candidates, this might output additional information in JSON with perhaps semantic tuples (
subject
,predicate
,object
or shortenedspo
) for standardization for clients to consume withid
,name
,value
fields as String type. Likely we can skipsubject
since it's the reconciliation candidate entity, so justpredicate
= name,object
= value in the output withid
as well.s:San Franciso p:partOf o: San Francisco Bay Area
s:San Francisco p:inception o:29 June 1776
The text was updated successfully, but these errors were encountered: