Open GoogleCodeExporter opened 9 years ago
We might be able to implement exact matching by surrounding the query with
quotes - would that work ?
Original comment by masou...@google.com
on 16 Nov 2010 at 7:52
How would you feel about having an "advanced" link that basically opens up a
mini queryeditor inside the dropdown?
Attached screenshots.
Thoughts?
Original comment by daep...@google.com
on 19 Nov 2010 at 12:16
Attachments:
Very cool! But, I would categorize the mini queryeditor as an "advanced"
"advanced" option. There is still a passionate need for expressing just the
basic limiters that are available in the Search API itself, with thinking about
MQL or the use of mql_filter. Which I mentioned on the email thread and recap
now: 1. exact match against topic name 2. exact match against topic name that
includes alias name (hmm, do we need an exclude also?) If we had facets like
we do in Google Refine...well, the world of Freebase search would be a much
better place ! You'll get there... this is a great start.
Original comment by thadguidry
on 19 Nov 2010 at 2:27
It would be nice to have a few "generic" tabs/facets to the right of the input
box that provide a MQL instant example for commonly used things like I
mentioned above. Exact match on topic, exact not including aliases, etc...
that would be phenomenal...then I wouldn't have to even think about MQL..and
the community could just make suggestions to add them to that "Special filters"
Example page that is shown when the user clicks on the tab... similar to how we
already have examples in Query Editor now ! Awesome ideas guys !
Original comment by thadguidry
on 19 Nov 2010 at 2:33
We are leaning towards something like the attached screen shots. Will these two
options be sufficient for your use case?
Original comment by daep...@google.com
on 23 Nov 2010 at 1:16
Attachments:
No we have to 3 options:
1. Exact match on name
2. Exact match on name or alias
3. Custom MQL
Why ? Try this simple word "black"
You get the continent of Africa because someone typed in an alias (and it
probably shouldn't really be returned as a result, it's Africa, not African.
Aliases are great, but we have to be able to exclude them as well, it's a 2nd
requirement to have a name only match. So let's get all 3 options available.
And probably perhaps make the text & checkboxes the same text size as results.
Finally, I would prefill the Custom MQL option like you have when user clicks
it (don't make it simply blank with a Json wrapper) The id: & name: at a
minimum. Great job guys, your flying high and reaching the stars!
Original comment by thadguidry
on 23 Nov 2010 at 3:04
OH, one more thing... will the options be a callable preference ? So let's say
that someone like me using Refine and integrates Suggest, would like to have
the preference locked. And Refine could pass the preference to Suggest ? Not
sure how that would work, but you get the idea. If I'm spending 4 hours in
Refine and only working with scientific data, then I'm going to use Exact match
on name, over and over and wouldn't want to click on it each time but somehow
tell Refine to tell Suggest to keep the option checked. Or my custom MQL for
that matter.
Original comment by thadguidry
on 23 Nov 2010 at 3:08
@thadguidry:
We're going through a full design review of this feature, so rest assured the
visual design will be cleaned up and consistent with the UI. However, right now
the focus is on how to integrate this feature seamlessly into the UI with
minimal intrusion. For example, changing the markup structure of suggest is
non-trivial for compatibility reasons, so we have to look at how we can add
this feature without changing this dramatically (and making sure the CSS works
with or without this turned on). As well, the "advanced" link is currently in
the "status" bar, which itself is an optional parameter. What happens if a user
calls the "advanced" parameter, but has "status" set to false? For that reason,
it may make more sense to add the "advanced" toggle to the bottom bar, next to
the "more" link, which is generally a more stable element (but isn't available
until a user has typed something). We'll sort it out, this is just the usual
process we go through with these features—we're just trying to do it more in
the open now ;-)
Original comment by kconra...@google.com
on 23 Nov 2010 at 3:34
Glad to hear that. And so it's non-trivial for compatibility reasons for those
customer using Suggest out there on their sites ? Is that what you mean ? The
rest of your response I understood and is throughly logical.
Original comment by thadguidry
on 23 Nov 2010 at 4:10
Yes, there are people using suggest on their sites, some with custom styling,
etc. Obviously, they can stick with an older version if necessary, but we'd
like to make updates as painless (and compelling) as possible. We want to keep
freebase-suggest a relatively lightweight plugin, so we're trying to avoid
bloated markup as much as possible (especially as this is a fairly "advanced"
feature).
Original comment by kconra...@google.com
on 23 Nov 2010 at 4:28
Then why not just copy it's code and make a Freebase-site Suggest2 that has the
advanced features to use on the Freebase site, or within other power tools like
Refine or Acre apps that care to use Suggest2 advanced features. And keep
Suggest1 as it is a lightweight plugin. My idea is that there are 2 user
groups here.. one needing advanced features and the other not.
Original comment by thadguidry
on 23 Nov 2010 at 4:34
@kconragan - We could treat the status bar like a header element that appears
if either status or advanced is set to true.
@thadguidry - I wasn't seeing that much difference between just the name query
and the name/alias query, since the name/alias query needs to be separate "or"
queries and as a first pass was just concatenating the two results, therefore
the first 100 results are the same as just the name query.
The advanced features should be configurable at initialization but this does
beg the question of whether or not these parameters can be modified by the user
even though the page that initialized it may NOT want you to. Also, if you
bring up the web inspector/firebug, you can theoretically call suggest on the
input again with your own parameters which may allow a greasemonkey script that
re-initializes suggest with your own advanced parameters.
Original comment by daep...@google.com
on 23 Nov 2010 at 6:00
If suggest was initialized with a type and mql_filter param, would you expect
the exact name match and the custom mql option to use those parameters?
For example, if suggest was instantiated with:
$(input).suggest({
type: ["/sports/pro_athlete", "/people/deceased_person"],
mql_filter: [{"/people/person/date_of_birth": "1900"}]
});
Do we apply these constraints to the exact name/alias match and custom mql
queries?
Original comment by daep...@google.com
on 23 Nov 2010 at 6:21
Also, I wonder if there should be a MACRO-like feature for the custom mql
option so that a special variable will be replaced with what's in the input
field? This is like the "Variables" tab in queryeditor. Thoughts?
Original comment by daep...@google.com
on 23 Nov 2010 at 6:25
^ So if I have this:
[{
id: null,
name: "$INPUT",
type: "/film/film"
}]
$INPUT will be replaced with the input value
Original comment by daep...@google.com
on 23 Nov 2010 at 6:33
Hmm, Remembering the instantiation of a type & a mql_filter might be something
useful. Although those instantiation options could prove useful to others like
Gordan. It's basically this: We have recon services and search services... we
give them a few parameters and can get results... WHOA ! too many results for
me! hurts my eyes and some of these results need to be filtered out completely.
So, we filter or limit those even more, by name, alias, or some custom
mql_filter code. The mql_filter code should be an instantiation option, I
would think, and type would be useful as well. I could see Matchmaker getting
better with those available to it. Regarding you direct question if we should
apply type and ml_filter constraints to exact name/alias match : Not always,
but the ability would be nice. Regarding applying those constraints to custom
mql queries...eh, that's probably going overboard and into the realm of a
custom custom Suggest. Check with Gordon and perhaps Jon who uses Refine for
loading and Reconciliation, I'd like their opinion here also before we get
further.
Original comment by thadguidry
on 23 Nov 2010 at 6:42
Regarding the special variable, Yeah, I like that $INPUT
Original comment by thadguidry
on 23 Nov 2010 at 6:47
The latest mock and prototype can be found here:
http://sandbox.freebaseapps.com/advanced_suggest
Original comment by daep...@google.com
on 29 Nov 2010 at 9:22
Great progress! I worry that this will only be used by the experts who know
their MQL very comfortably as it is implemented currently. I assume we will
have helpful examples for common issues like removing all results of a type
/book/book_edition if I don't know what type I am looking for?
ANother question: How will we get the advance MQL filter back to the default
state?
Original comment by gmack...@google.com
on 30 Nov 2010 at 6:51
You can now save your custom mql queries.
http://sandbox.freebaseapps.com/advanced_suggest
For starters, it's just using localStorage so your queries won't be
available across domains.
Try it out and let us know what you think.
Original comment by daep...@google.com
on 3 Dec 2010 at 2:12
Dae, that's RICH ! Very nice. One use case I had:
http://awesomescreenshot.com/05846xacc
Original comment by thadguidry
on 3 Dec 2010 at 2:30
Can we make Clear All always display on the advanced interface(at least when
this gets up to Production). Right now it only shows when I hover, and I don't
see the usefulness with that effect for the Clear All feature. That's a
feature a user show always know about without hovering.
Original comment by thadguidry
on 3 Dec 2010 at 2:35
^^ done
Original comment by daep...@google.com
on 3 Dec 2010 at 2:59
What's the status on this so far ? Can we expect this functionality in the
next 2 months ? Or do you think it will be longer than that because of Google
infrastructure migration ?
Original comment by thadguidry
on 10 Jan 2011 at 8:53
Original issue reported on code.google.com by
thadguidry
on 16 Nov 2010 at 4:27