Discussions on Roadmap of future features

I was thinking it'd be helpful to be able to link instances of types so that different terms are used to describe the same things, they could be identified together. For example, I was looking at the new sports teams that have been loaded thinking I might find Manchester United. They are a "football" team, but they would be considered a "soccer" team in the US.

Of course, this could lead to potential problems with contributors arguing about things that are "almost the same", but having that sort of cross-reference would probably be helpful too.

We're planning to add an alias or 'also known as' capability for types (the same way we have one for topics) - this should address the situation you describe. Hope to have this feature in the next few weeks.

I would like to see some way to track a page or even a subset of a page. For example I just added information to the page for Paul S. Kemp an author I read. If someone adds a new book to this list I might want to know about it vs any change to his information.

We've been talking about hooking up RSS feeds from domains, topics and/or lists - would this do the trick?

I'd like to see something that works like Wikipedia's watchlist feature. An RSS feed containing changes to all my watched topics would be 90% of this functionality, with the last 10% being that I'd be notified of changes to watched topics when I signed in to Freebase.

Individual RSS feeds for each topic would be unmanageable in most RSS readers, especially when we're talking about ~100 watched topics (on Wikipedia, I have ~200, which I think is typical, and some users have > 1000).

Freebase has a very nice model and overall interface. It is quite similar to a system we have been setting up internally to a US Government organization. We are a scientific organization and would very much like to contribute much of our content to the public domain. However, certain content must remain internal for some time period before being released, and some content may never be appropriate for broad release.

Would you consider adding the concept of groups to your overall model such that a given user could publish publicly but also to defined groups? If your API then allowed some form of token-based authentication or a method that could support machine interfaces, applications could be written for a specific set of content using a user credential from a group to which the content was published. This would open up the possibility for topics to pass through some level of peer review required by the scientific community before being released to the broader public.

Thanks for the post. This is a request that has come up quite often, and its clearly a good idea. However, we've been a bit reluctant to bite that off initially as a matter of focus. We're interested in initally creating groups as you describe and potentially developing specialized views for those groups, but we aren't presently thinking of completely restricting view access to those outside the group for the time being.

If that data didn't appear on the main topic view but was still accessible to everyone, would that be acceptable?

Sorry its taken a bit to get back to this. Unfortunately, we'd be dealing with pre-publication information in a lot of cases and would need a way of tighly controlling who has access to what. If the "publish topic" concept could move beyond personal to public and include personal to group to public, that would be great.

Any chance your codebase might be made open source at some point? We could take the code down a path internally of limited publication with a hook into the public freebase at the end of the pipeline.

We've heard this request before and it makes some sense. We're looking at a general method for copying types so that you could, for instance, copy types from sandbox to freebase. This kind of capability might meet your described need as well.

Has there been any progress on this? I'm also interested in cloning types but I'm also interested in cloning topics. For example, I may describe a topic using 20 attributes. I then want to describe another topic that is similar in all but one way. The only way I can see to do this is to re-enter all 20 attributes. Is it possible to provide an option for a new topic to inherit some or all attributes from an existing topic? This would allow me to just change the 1 attribute instead of all 20.

Actually, we're working more actively on this kind of feature than the one I previously described - something we're calling 'extended types', which would allow you to select an existing type to use all its properties but be able to add new properties to it - but this is probably at least a few weeks off at this point.

What do you think is most important? Adding, removing or relabeling properties from an extended type?

Depends on what you mean. If you are referring to the process of making an extended type, then it would be most important to exclude specific properties from the existing type with a single step. If the extended type is then treated as a regular type afterwards, the user could always add new types specific to it.

Brian, have you looked at using MQL (Metaweb Query Language) directly for some of the more advanced operations, such as mass creation of topics with very similar values, duplicating a type with minor changes, or querying for all topics meeting certain criteria? It's a more powerful way for developers to use Freebase data without going through the UI.

If you're interested, the API is a good place to start. Try things in the query editor on sandbox to see how they work.

Thanks if this was to me (Ed not Brian). I plan to delve into MQL soon. I'm trying to get a decent handle on data modeling first. Also, programming skill is not one of my strongest attributes.

You've got the basic idea right... we've gotten a fair amount of feedback that this is confusing, so we're going to take some steps to clarify the relationship between user (your Freebase persona, editable only by you) and person (a topic about a person that can be edited by anyone). We will try to minimize the redundant properties and make the labels more obvious.

From this page: http://www.freebase.com/view/filter?id=/people/person
"A person topic is distinct from a user in Metaweb. Users have profiles that can only be edited by the users themselves. A person topic can be edited by anyone and is intended as a factual representation of details about a person."

We also changed the properties on your user profile. 'My Full name' is now a simple text field. And 'Me as a topic on Freebase' is a link to your person topic.

Good suggestion. Yes, we've been planning to add this feature - just neglected to include it in this list.

Multilingual data is supported by our underlying data store and language flexibility is partly implemented—but right now, every user’s display language is forcibly set to English. This will change at some point, but keep the pressure on. (-:

ooh that's awesome! the only thing that gets me more excited than well structured information is a piece of software that takes other languages into account :P

crism, hello,
what about supporting a translation for all the Types as well.
not talking about translating the data only (like name in all language for a town for example) but to actually create a Type in language other then english, and have the system know its a translation of the same type, which is written in English.

thanks,
Doron.

Doron, part of the point of our multilingual structure is that the same thing may exist in the system with different names in different languages, but that it remains the same thing . A person, une personne, ein Person, 사람, 人, are all the same concept. We definitely don’t want a different type for person-in-French, person-in-German, etc.
I think, rereading your comment, that it may not be clear that the types in our system are not substantially different from the instances; a particular type, such as Person , is just an instance of Type . Accordingly, the labels on Person (and all of its properties) can be changed just as easily as the labels on Japan can be.

crism, i think i understand most of what you said, but i still dont know (from reading your reply and some of the Help documents) what the system can and cannot do right now, and how to actually do it. so here are some follow up questions.
1. lets say i want to create a new type in freebase, one that do not exist yet at all. can i give it a name in languages other then english?
2. can freebase have a single type (like Person) but display the translation of its name in other language?
3. lets say i want all the types i work with to be displayed in Japaneese - can i go to the screen which lets me edit an existing Type properties, and somehow there to declare that this Type is not only known as "Person" but also with the word in Japaneese that mean Person?
4. after i create this "Translation", will the system know to display (now, or in the future) the name of this Type in another language to everyone who wants it?

i believe that if freebase will support this translation, and if it is done right (according to specific rules - like using singular or plural ) will be a key to Semantic web. and i do wish you can (somehow) actually use not just auto-complete features to retain this consistency, but also some spellcheckers which will enforce the correct naming of Types and all other system parts.
thank you.

Right now, using the user interface, you cannot create strings labeled as anything other than English. You can do this directly using the query editor or the API, but then no users will see the result.
In brief: the underlying data model is multilingual, but right now the UI only shows and manipulates the English data.

so if there is only english, what about names of types. Does names have to be translated? For instance if the name of the sports facility is "Olympiastadion Berlin" (german) does this have to be "Olympic stadium Berlin" (english) or its realname?
as i know proper names are not translated?

I think that in general, if there is no standard English name for something, the native language name should be used. Most people will know it by that name, if they know it at all.

Any schedule on multi-language support for freebase. 

I can’t definitively answer the question about the schedule, but this seems like a good place to point to my more detailed blog post about internationalization in Freebase. We have support in the data model; it’s just not exposed in the Freebase.com Web client.

Are there any articles in common/topic that aren't English?

For example (get the country named "Verenigd Koninkrijk" and it's ID so we can look up if this topic has articles or images):
{
"id" : [
{}
],
"name" : [
{
"lang" : "/lang/nl",
"value" : "Verenigd Koninkrijk"
}
],
"type" : "/location/country"
}

The only id available is /en/united_kingdom haven't seen anything else but /en/.. or guid for any found topic. Now to get the guid of the article associated with the topic:

{
"article" : [
{
"id" : null
}
],
"id" : "/en/united_kingdom",
"type" : "/common/topic"
}

This gives me a guid linking to the English article.

Is there something I need to change in the query or is there no article available in other languages?

We don’t currently import articles from any source other than the English Wikipedia, so there aren’t yet any non-English articles. Importing other versions of Wikipedia is on the to-do list, but I still couldn’t tell you what the schedule is on this. Keep asking, though; more user demand will help move it up.

Well, I just wanted to help demanding the easy "language" editing of topics.

For instance I entered a german film, before I realised the fact, that the freebase already IS multilingual, only the webclient is not.

One could for instance display an array of flags above the topic, to easily select which language one wants to edit. Also to add a new language to the topic. Of course, the linked objects in the topic should also deliver their translated versions if present.

I think as more and more user join freebase, the multilingual webfrontend becomes more and more important for:
1. gathering information in different languages from the users, although the bots aren't currently extracting other language wikipedia
2. avoid mistakes like mine of users, who at first not realise, the multilingualism is there but not shown.

+1 for updated web client

We're currently discussing adding some geo-coding functionality so that you know that something is "in" something by its geolocation. The location contains/contained by hierarchy is going to be problematic for exactly the reasons that you just outlined, and is a poor substitute for a fully-fledged map-based system.

Given that, it still makes sense to have a relationship between a town and it's neighborhoods or districts.

actually, i remember seeing something like this somewhere, but I can't seem to retrace my steps to it :P

Not sure this is going to answer any questions for you right now, but hopefully it will updated and made more current soon. http://www.freebase.com/view/%239202a8c04000641f80000000011ad98b

Actually, show/empty fields has been around for a while -- its supposed to remember what you set on one page and that should persist from topic to topic until you change it. If this isn't working it would likely be because you have cookies disabled. Otherwise, perhaps you're seeing a bug?

My best case scenario is that I could set in my account settings to show or hide empty fields. As it is, I have to click show empty fields on every page that I want to add data, then click to add data.

Ed, I don't know of any such native clients. Why, were you thinking of writing one? ;)

Thanks for the suggestion. This is probably a ways off in the future.

This is something we've been talking about doing for a while now - and we completely agree it makes sense. Hopefully this can get implemented in the next couple of releases.

To clarify, you'd like to be able to sort the order of topics of an enumerated type - from the schema editing UI so that everyone viewing options for that enumeration will see them in that order?

Exactly.

On the topic of sorting, I would like to eventually like to have the option for one-button alphabetical sorting too.

In my last post I meant one-click alphabetical sorting. 

Again on the topic of sorting, I would like to sort included properties in the schema regardless of which included type they belong to. The sorting doesn't necessarily need to include user defined properties at this time. But the included properties are already lumped into one group and I would like to sort that group.

Currently, it is possible to change the order of groups of included properties by reordering the included types. However, there are times when included types have properties that are rarely used. For example, the proposed Written work type contains three date fields. It is great that it has that flexibility... but I only need one date most of the time and it is the bottom of the three. I would therefore like to push those other date properties down to the bottom of the included properties list. I know this is something that I can do on my own with MQL, but it would be great to have this flexibility in the UI.

Is UI sorting in the works? Seem like a pretty basic and necessary feature to be able to sort any list by properties, i.e. for Film: sort by name, sort by  Initial release date, sort by actor, etc..

It depends on what you're trying to sort. We don't currently support sorting on the search results and filter pages, if that's what you mean. You can submit a feature request here, if you like.

You can, however, sort tabular data on individual topics. For example, if you go to the topic for Steve Martin, and you wanted to sort the list of films he's written, you can do that by clicking the "edit" button next to "film writing credits" and then clicking the column header for either "film" (to sort by title) or "initial release date". When you click "save", the films will be sorted in the order you chose (until someone else decides to sort them in a different order, of course).

Actually, sorting is something we're hoping to enable from the filter/type pages -- which would be equivalent to what Jeff describes, but a bit more flexible -- so that you could say, filter Martin Scorsese's films and then sort them by release date. We hope to have this functionality available within the next few months.

Does this include sorting by most recent on the type pages?  This would be good.  Currently it shows the first added, right?

Sorting by timestamp in either direction is definitely in scope for this feature. Currently it shows oldest to newest on most type pages.

That's a really interesting idea! It may be tough to model that, but it seems like a reasonable feature for the interface. I can see that often when you're building on existing types (even just building on /common/topic) that the properties of the base types you're dealing sometimes have more meaning in the more specific type.

Yep, especially if the goal is to make generalized modeling modules that can be recombined in different ways. Modularity seems to be a goal here for the types that were developed by Metaweb staff and that makes sense for maximizing the flexibility of content context. 

I would like to have the ability to nest CVTs within CVTs for the same reason. That way, when you click on a property within the CVT box, another CVT box can pop up to store properties nested within the context of the first CVT. The information within all the boxes could then be stored as just a single CVT record. For example, if a topic is not expected to be entered as a standard floating point unit type, then it would be nice to nest a user defined Floating point number CVT that asks for Unit of Measurement within a parent CVT. The entry could then be stored just as if the unit type was defined in the parent CVT model.

This is possible through the UI.  When you create a property, it automatically appears on the schema page of its expected type under the heading "Suggested Properties". Just double-click on the suggested property and give it a name, and it will be created as a reverse property.

Thanks! That is great except how are the suggested properties linked in without first adding an expected link to the type? For example, it seems that I am able to add a suggested type of Journal issue only if I had already added it as an expected type, which means that I need to go back and remove the expected type I just added. Is there a better way? Is there any documentation on this feature?

I found the suggested properties help topic. For some reason it didn't click for me the first time I read it. Now I get it. However, my question about duplicate links in order to reciprocate a link still remains. The process seems overly complicated.

I'm not sure what you mean about duplicate links in order to reciprocate a link. The workflow to create a reciprocal link should be:

1. Create a property
2. Select an expected type
3. Go to the schema editor for the expected type
4. Double-click the incoming property in the "suggested properties" list
5. Name the property

Thanks for clarifying Jeff. I was confused as to which schema to name the suggested type. This feature will really increase my efficiency. Thanks for walking me through it.

I'm going back through my data models to properly reciprocate their properties using suggested types. The process involves deleting the property I thought I was linking in and then linking in the appropriate suggested type using the same name. This is relatively simple but was not intuitive. It would be helpful if the data modeling guide was clearer on how to model with suggested types. I also think that my case will not be unique. Others will probably create the type they expect to link in when defining the property. For this reason, I would like to add to the UI wishlist some way to link in to an existing or new type when defining the properties of the focal type.

Hi, this has been addressed in the newest version of relevance and will be pushed to production soon. It's working on sandbox (which gets new software ahead of production):

http://sandbox.freebase.com/view/search?limit=30&start=0&query=schroder

Great!

Such a page does, in fact, exist, but it hasn't been getting much TLC (attention). We've also tried to keep things current with the 'mass data operation' type. This seems to be a little more up-to-date.

Ed, are you talking about the list of topics on the right, while looking at the schema editing view? That would be a good idea, so thanks for the suggestion; if I’ve misunderstood, please let me know.

Spot on Chris. Thanks!

Is this still in the queue? If so, any idea when it will be implemented?

Schema editor is currently being revised; I'm not sure of the timeline, or whether something like this will be included, but I'll pass this along in case it got lost the first time.

Thanks. If this feature is added it would allow me to simplify the naming of motorcycle makes, models, etc. among other things.

Ed, there are a number of changes in the works -- hoping to provide a preview soon. One change is that we'll have a new filter view that shows any/all properties you want to see when viewing a list of topics of a type -- which can include any disambiguating properties you'd like.

We're also redoing schema editor, although its not 100% certain that we'll continue to display the list of topics on the same page.

Where do you find you most often add instances? From the schema page or the filter/type page? 

The changes sound great. I'm looking forward to them. 

I'm more interested in advancing the models than using the data, at least in the short term. Most of my time is therefore spent in the schema view.

I've started initiating types from the domain page instead of creating them as new properties of existing types because it caused fewer problems. It's been awhile since I really focused on model building here so I can't point out specific problems but I'll keep track of it. I usually file a feature request/bug or provide feedback when I can describe what seems not to be working well. I filed a couple instances of feedback and bugs this week.

Most often I create new topics when describing existing topics through their type properties. When modeling, I will often create new topics and delete existing topics through the schema view. It's just easier to stay on the same page. So, if there are two topics named 1200R it is nice to have the disambiguation to know which one to delete. Maybe the split view will help that. Either way, the cache would need to be refreshed and the page reloaded. It would be nice to have a single button that did that. 

Over the past month or two I've tried to start a modeling marathon for one reason or another and hit a few bugs and loss of previously available functions that slowed me down so much I stopped without really getting started. I understand the schema editor is under development so it seemed better to just wait.

I don't use Sandbox because I would rather work on a new model in Freebase then spend my time copying them. Y'all have been really helpful moving things around but I build a lot of models. How about adding a feature that allows models in Sandbox to be copied to a specified domain in Freebase and vice versa? 

Tangent: I've noticed that the URLs to some topics are those topic names while others are 9202a8c... Why is this? I first noticed it on a list of hockey players that was linked through the home page a couple months ago. When I send people links it is nicer when the link makes sense. I can understand why CVTs have these strange names but not why that is done for standard topics and types.

It depends on how your website is set up. More common is that external sites use the Freebase read API to present data from Freebase. As data is updated in Freebase, your website would then also be updated. If you're hoping changes on your website would be written back to Freebase, you'd have to use Freebase's write API - and handling authentication would make this more complex.

Hey Mike,

I thought this would be cool too.  Unfortunately, it would be pretty "un-freebasy-semantic"; we would be searching for display name matches only since the MozSearch/OpenSearch doesn't support much more than that.

That being said, I did write a very rudimentary example that returns the top 30 results (no autocomplete).  I'll send it to you.

Actually, someone already wrote one… but it broke when the Freebase search API changed. It’s being rewritten, and we will be sure to announce it when it’s ready!

If you build one that can take suggestions, you should definitely put up a prominent link on this site.

I wrote one for my personal use recently. Nothing fancy, but it at least allows me to quickly search Freebase. I just needed to get permission to use the Freebase icon before I make it public. Let me know if this is an issue, otherwise, you can install it from here.

I have re-written the search plugin (using OpenSearch description) that includes suggestions. Please delete the older version and replace it with this. I believe it will only work with Firefox for now, IE7 support will come later. Any feedback/suggestions are appreciated.

The title should say "Included properties" not "Included types".

BTW: The memories described in this thread all referred to the Topic view. Most of my other recent suggestions referred to the Schema view.

I think I understand your problem, Ed, but I’m not sure. When I look at the Database type page, I don’t see the “Topic(s)” property listed. That’s because the current filter only shows the first eight properties, including disambiguators of other expected types, and “Topic(s)” is too far down the list. If you reorder the properties in the schema, it will be visible on the current filter page.

When I look at the Database topic page, I see Bird listed; filtering by “Name” would restrict that list to Bird, so I don’t think that’s the problem you’re talking about; please let me know if I’m wrong.

Thanks Chris. I wasn't aware of the eight property limit of the filter. I'll reorder the properties so that "Topic(s)" is higher in the list.

Hi Ed, the filter page is going through redesign right now. I believe the a new filter page will allow you to do exactly what you need, filtering by properties you can select and choose, whereas now the filters are fixed. Stay tuned.

Hi Ed,

If you're logged in, your home page has links to two discussion lists: 1) "replies to you" and 2) "watched discussions". You can also view the same on the "discussion activity for <user>" page.

Does this serve your needs?

Thanks Faye! The "discussion activity for <user>" page is exactly what I wanted. Can these filters be linked to the discussion hub so users can easily access all their discussions?

Can you also add a filter for all of a users discussions even if they are not watched or replied to? Sometimes I forget to watch a discussion and if no one replies to it I would not be able to find it.

Hi Ed, the "http://www.freebase.com/user/discuss" page can be accessed from the home page (freebase.com when you're logged in) by clicking the "View More" button at the end of the discussion section on that page.

I'm not aware of a page that lets you see all of a user's posts regardless of replies. Sounds like a good feature request to me. Some related pages are:

Latest discussion posts, unfiltered

Unanswered discussion posts, filterable by domain admin

Julian,

These are interesting ideas. Freebase’s primary focus is on structured data, which is a little different from textual data found in encyclopædiæ. We do intend to have differing views of that structured data, particularly through catalog, domain-specific, and commons views of topics. That’s not really the same as different levels of understanding, but I think that structured, bite-sized information gets processed a little differently then textual matter (though I am no expert on the subject).

As for the textual blurbs: they are not really the focus of Freebase. However, there has been some talk of allowing multiple blurbs to be associated with a single topic; it is not yet clear how that will end up, though.

If you have any ideas on how Freebase could be more variable with respect to comprehension levels, please do share them.

Hi gromul, nice work. You might also want to take a look at fuzziebrain's plugin which makes use of the search api to provide suggestions as you type.

Thanks for the link. I tried it out but don't see the suggestions working at the moment.

You might have installed the very first version that has no suggestions provided. I have updated my blog to avoid confusion.

The plugin is still very raw and I'm constantly modifying the codebase. If you wish to track my progress, please uninstall any older version, clear your browser cache, then reinstall the plugin from here.

PS: Glad to see other efforts in developing search plugins for Freebase. Currently, my plugin only supports Firefox. I would appreciate any pointers on how to port the plugin to work with IE7/8. Does IE fully support OpenSearch suggestions extension?

It's working great now, thanks. You should also upload it to mycroft, that's where I generally search for plugins: http://mycroft.mozdev.org/contribute.html

>Does IE fully support OpenSearch suggestions extension?

I haven't tested the plugins yet on IE7, but as long as they are OpenSearch and you don't use the POST request they should work. Do you use OpenSearch or Sherlock?

Glad it's working for you now.

I normally would post it on Mycroft, but decided to hold off till it is more stable. And yes, it is complies with the OpenSearch specifications and uses GET requests.

This feature would be useful for other domains too so that users can give props to other users that help advance schema. Currently, administrators can set users as administrators and user edits can be tracked. However, not all administrators contribute. Further, users may make suggestions that result in major improvements without making the actual changes. It would be nice if creators/administrators could give credit for these suggestions in a "Contributions by" type attribute that is close to "Created by".

Also, it looks like the limit is set to 100 search results even if there are more. I would like to see all of the search results.  :)