Discussions on Jewlib

Thank you,

is there also the possibility to use an operator like "OR", e.g. Country name is "United Kingdom" or "Ireland"?

best regards,

Frank

Opened a bug, CLI-9193

It's because the client is not accepting edits to boolean properties that are not set to restricted to a single value.

Hi Frank,

Client logic displays only types in the Commons on the Consumer Page of a topic (i.e. url has /view/ before topic id). All types, including user types, are displayed on the topic's Edit Page (substitute /view/ with /edit/topic/). For the Einstein page you quoted, this is:

http://jewlib.www.jewlib.freebase.com/edit/topic/en/albert_einstein

I think the reasoning behind this is that it's best to show only the reviewed, high quality types to new visitors.

Unfortunately that also hides good quality user types which haven't yet made it to the commons.

However, you can get the base types to be shown by appending /-/base/jewlib to the end of the url as so:

http://www.freebase.com/view/en/albert_einstein/-/base/jewlib 

Masouras, good question...I just copied the address out of the browser window.

 I understand, but don't you think it might be helpful if there will be a clearer sign on additional content except the "Edit and show details"-button?

 f. 

Hi there,

 I wonder if there is a possibility to set a more prominent link to (non-commons)-user provided types in future. As I pointed out before, I am really not happy with the fact that user contributed data which is not contained in the common-types is hidden. In my opinion the "Edit and show details button" is irritating. Just to give one  example:

Freebase-standard-view:

http://www.freebase.com/view/guid/9202a8c04000641f800000000c38d9a9

Jewlib (with /-/base/jewlib extension):

http://www.freebase.com/view/guid/9202a8c04000641f800000000c38d9a9/-/base/jewlib

cheers,

Frank 

If this is important to you, I would open a bug report/feature request at http://bugs.freebase.com  There was a bunch of negative feedback when the recent redesign was introduced, but I've never seen any indication that the designers think anything other than they got it exactly right.  Having a bug report will allow you to track progress and others to vote to support your request.

Personally, I think that "show details" is much, much too well hidden.  Not only is it way at the bottom of the screen so that you have to scroll down to even see it, but then it's in the 2nd half of the compound "edit and show details." 

If it were me, I'd have a separate button for "Show details" (even if it went to the same page) and I'd have it at the top of the screen.  This would allow me to instrument the UI to see what the users were actually selecting.  If I were optimizing for the user instead of programming effort or computational efficiency, I'd only have the "Show Details" button present and/or active if there were actually additional details to be shown which were not displayed on the main topic page.

It may be that Metaweb is trying to push people to design their own applications instead of depending on the Freebase.com web client, but that, in my opinion, would be a mistake. 

It would be great if you open a bug report/feature. Thank you!

 And: Yes, I am totally with you...

f.

>> I wonder if there is a possibility to set a more prominent link

>> to (non-commons)-user provided types in future. As I pointed out

>> before, I am really not happy with the fact that user contributed data

>> which is not contained in the common-types is hidden.

 Yes, it's a problem.  We've been trying to rethink how to surface good bases but it's been a slow process as there have been a bunch of other big projects going on.  It's next on the list, though.

> I've never seen any indication that the designers think anything other

> than they got it exactly right.

If that's just based on the fact that there hasn't been a design change yet, I think that's an unfair statement.

Jason - It's based on more than inaction.  There's an extensive discussion from a couple months ago where the only people who gave any indication that they thought there was a problem were the users.

http://lists.freebase.com/pipermail/freebase-experts/2009-June/000699.html

Swapping two buttons between the top and the bottom of the page, relabelling a button with a label that makes sense to users, or even adding a new button with a separate label (but that is wired to go to the same place) are 5 minute tasks (perhaps the last is 10 minutes), so they certainly could get prioritized without having a significant impact on other tasks.

I've got a lot more to say about this, but perhaps it's more appropriate for email... 

Yes, that might be a interim solution. I personally think that it would be better to name all the types which are existent for a topic.  Maybe you can distinguish between common-types and user-created-types by using different visual designs or sth like that?

Especially in the case of topics which are not described by common type it seems to me complicated that you only get to the bases which contain the types. (and the have to search again for the topic)

f. 

Sorry for the delayed reply.  I've been moving house and haven't had any credits in my "spare time" account.

James is totally correct.  He did offer an encouraging reply to that thread.  Unfortunately, it came at the tail end after I'd already tuned the thread out as not going anywhere, so it failed to impress itself on my psyche.

I'm not sure how many iterations have been done in the last two months, but I just double checked the current display rendering and I think another iteration or two could improve things more.  Since the base-specific consumer page is much more nicely styled than the generic edit page, it sounds like that's an additional navigation destination that needs to be considered in the mix as well.

Frank - I think my wording may have mislead you.  I was suggesting that *you* file a bug report since you are the one who is directly affected and most interested in seeing this fixed.  I'm not planning on filing a bug report myself.

It depends on how you're loading the data, but if you're just trying to load a bunch of book/author pairs, you can do it by duplicating the book on two lines. E.g.:

BookA / Author1

BookA / Author2

The two BookAs can be merged to the same topic, so you should end up with two authors on the same book. UNLESS you are creating a new book, in which case two book topics will be created. (Note that I haven't actually tried this, but I can't think of a reason it shouldn't work.) 

There's no way to put multiple values for a non-unique property in one line, though.

Great! thanx

 f. 

| UNLESS you are creating a new book, in which case two book topics will be created.

@jeff Actually, you can also add new books this way and only a single book will be created. The tool matches items with the same name.

Frank, we don't actually have per-base traffic statistics - other than the ad-hoc, top bases stats we get from google analytics. We are evaluating our next steps with Bases and whether we can expose any of that to the base owners.

 I assume you want base traffic statistics rather than new topics/users - which is something you can get a good idea about from the base newsfed. 

I believe it's related to this post about image licenses:

image thumbnailing

Until somebody with deep in the bowels edit capabilities comes out of vacation mode, you could try an experiment.

 On Sandbox, could you try adding your image to the header for your base there? See if the same thumbnailing issue occurs again?

If not, you could try uploading again to your freebase base, maybe with a slight change in file name? I've looked at other bases with the same dimensions for images, and not seen the reduced to 150 in length issue there.

Getting a bit technical here...

Looking at the header image used for my ZX Spectrum base, I note that superalecf explicitly linked it to have a CC-by license on 1 July, which will be why that doesn't get reduced.

Playing around on sandbox, it looks like the client isn't asserting a CC-by license for newly uploaded images via the edit base page, which it possibly should be.

Frank, if you're happy to mark your image as being CC-by licensed, run this query which I think will solve your issue.

Sorry about all this... it was actually a mistake.  This image policy change was only supposed to be for images uploaded by Metaweb staff... not all uploaded images.  We'll get that fixed. 

In the meantime, I do believe pak21's query will fix the problem.

no worries...I tried both, I run the query as suggested by pak21 and I uploaded a header image with a slightly modified filename. The query did no fix the problem.

Also, I the image was showing as a thumbnail in the sandbox. Mmmh... Just let me know when you will get that fixed.

best regards,

Frank

Hoo boy, complicated stuff.  Back from a long weekend away and let me try and explain the background here.

 Basically, there's precedent out there that says it's Fair Use to use small images (150x150) without any specific license like CC-BY, GFDL, etc., but that using higher res images may not be fair use.  Therefore, we set up something in our backend so that requests for images that *don't* have a specific license will be limited to 150x150.  This would apply to those that are in Freebase as "Fair Use" as well as those that were uploaded without any license/terms at all, before we started requiring it at upload time.

Most image uploads happen via the gallery thing on the topic page.  But, there is one category of image that's uploaded differently: base header images.  When you upload a base header image, it goes (well, went) into the system with no license attached -- none at all, just blank.  That meant that all those base header images were going to be affected by the 150x150 limit, which would be a problem.

 We talked about this and decided that, absent any explicit statement to the contrary, uploads on via the base admin interface are presumably under the same terms as the rest of Freebase, as described in our TOS.  That is, CC-BY.  So we ran a query to take all those base header images with no license terms and make them CC-BY rather than blank.

What seems to have happened here is that somehow -- nobody quite knows how -- frank's jewlib header image had picked up a "fair use" license setting somehow.  This means it didn't get turned to CC-BY at the same time as all the other base header images (because the query was only looking for those with no license at all), and that's why it is appearing tiny.

The fix is to use a mqlwrite query to add a CC-BY license to that header image.

I've Cc'd alecf, who will be able to tell us what MQL is needed to do that, or, if we're lucky, he'll just be able to do it and let us know when it's done ;)

Thank you very much for the compliments...I am o.k. at the moment.

 Just one question: Is there a possiblity to get statistics of the base. In the past I used google analytics for another project. The problem is, I have to paste some lines into the website-code...mmhhhh?

Hi there, I have a question. During the last weeks you changed some things on the view options of freebase-topics. This really looks good to me. But, I wonder about different detail levels of the topics. For example:

The first page of the Albert-Einstein-topic(http://www.freebase.com/view/en/albert_einstein/-/base/jewli) shows a lot of facts from different types.

In contrast to this e.g.the Adolph Frank topic (http://www.freebase.com/view/en/adolph_frank/-/base/jewlib)only shows the summary in browse-mode.

Is this just a bug?

 I ask because on jewlib-base (http://jewlib.freebase.com) we have a lot of data without summaries at the moment. In this context, It seems unpractical to me to change to "edi-mode" to get the facts we entered during the last months, like here:

http://www.freebase.com/view/guid/9202a8c04000641f800000000c38cd12/-/base/jewlib

or here:

http://www.freebase.com/edit/topic/guid/9202a8c04000641f800000000c38ef9a?domain=%2Fbase%2Fjewlib

 I hope you understand what I mean,

best regards,

Frank

Teething pains my friend, we are rolling out this 'New Look' for many templates, Consumer Page being the very first.

Look here on sandbox, which is running the upcoming code release for next week:

 http://www.sandbox-freebase.com/view/en/adolph_frank/-/base/jewlib

 I think Adolph is looking a bit better there.

Yes indeed, Adolph is looking much better in the sandbox ;)

 Thanks for the quick answer,

f.

Thank you very much for your offer. I will let you know when I am stucked with a problem.

Frank

Hi there,

 I am just wondering if the created views will update automatically. I e.g. added one more research tool:

http://jewlib.freebase.com/view/guid/9202a8c04000641f800000000ba3da1b

Will this one appear in the following view during the next days:

http://jewlib.freebase.com/view/base/jewlib/views/online_catalogs_and_databases

or do I have to create a new view?

 Thanks and best wishes

 Frank

The answer to that question is "a bit of both". Views do update automatically, but a view you create for a base shows only topics which are marked as being part of that base. This latter process doesn't happen automatically.

You can add any topic to your base by going to the "All topics" view of the base and then using the "Add more" button, or by manually adding the "/base/jewlib/topic" type to the topic itself. I've done this for the new topic you mentioned, so it should now appear. (Note that if you add a topic to a view by using the "Add more" button from that view, it will automatically satisfy the criteria to appear in that view).

Hope that makes sense - the whole "base topic" thing is confusing, and I believe is planned to be replaced "soon".

Thank you for your answer,

I understand. The problem is, if I add a few topics to a view,e.g. to

http://jewlib.freebase.com/view/base/jewlib/views/jewish_studies_research_collections_topics

the e.g. rel. research tools do not appear in:

 http://jewlib.freebase.com/view/base/jewlib/views/online_catalogs_and_databases

It is really to hard to add each topic manually to the different views...

If I use the Add more button at the "All topics"-view I am afraid of losing the overview...

I think I understand your issue, but I'll run through it just to check we're talking about the same thing :-)

1. You create a new research collection
2. You edit the "metadata available through" property of the new topic, creating a new online research tool.
3. The new online research tool doesn't appear in the second view.

If this is the issue, I'm glad to say it's easy to fix! Go to the schema for online research tool and add "/base/jewlib/topic" to the set of included types at the bottom of the page: this will mean that anything which is (in future) typed as an online research tool will automatically also acquire the magic "base topic" which makes it appear in your views. [ You may want to consider doing this for your other types as well ]

If your issue is something else, let me know and I'll see if I can help with that.

O.k. only one question is left: If somebody uses the "Research Collection"-type to create new topics, do these topics also appear in my views? This might be confusing, because not all research collections are relevant for Jewish Studies (as you could imagine).

 best regards,

 f.

Hi there, I have some problems in understanding what is going on. I will try to summarize.

 I created a few types during the last weeks. Among them is the "Jewish Studies Research Collection Type":

 http://jewlib.freebase.com/type/schema/base/jewlib/research_collection

The auto-fill function was fine up to now. For example when I added research collections to a specific Judaica Owner - see e.g.

http://jewlib.freebase.com/view/en/national_library_of_poland

the Owner also appear automaticly in the "research collection held by"-field

But after  I made some changes to different properties of the type, it does not work anymore and/or the tie between the types Jewish Studies Collection and Judaica Owner is not shown on "Judaica Owner"-topic views? (There are some topics which keep the field filled, like:

I have no idea, what to do. (Maybe it is no real problem, because the return link still works)

 best regards,

Frank

The Link is not really broken. Only the e.g. owner of the collection which has to appear in the field "collection held by" (I think) is not shown, like in (Just click the edit button under type Judaica Owner/Research collections:

 http://jewlib.freebase.com/view/en/yivo

http://jewlib.freebase.com/view/guid/9202a8c04000641f800000000ba4662b

http://jewlib.freebase.com/view/guid/9202a8c04000641f800000000ba4664f

 Non Judaica Owner (e.g. Originator) topics show the Judaica Owners in the field "collection held by, like:

 http://jewlib.freebase.com/view/en/alter_kacyzne

or

http://jewlib.freebase.com/view/en/general_jewish_labor_union

The only problem here is that the headline of each field is not shown.

best regards,

 Frank

p.s. At the first moment I was suprised about your human-like-answering bots ;)

The second issue, with the header not showing, looks like a bug. I'll file a ticket for that.

The first issue is not really an issue: you're seeing the "collection held by" property in the edit window because that property is non-unique. Nothing is displayed in the table view because there are no instances with multiple values, and the value that is present is the current topic. If you have a collection that is owned by more than one owner, the other owner(s) will appear in the table.