Freebase: Discussion about sandos

bigvivah: Changes reversed

2009-12-22T17:27:40.0013Z

Hi. Welcome to Freebase. Please don't take a topic which is about one thing and convert it into an entirely different thing. If you want to create a topic about an online Indian marriage service, please make it a separate topic. Before you do that, you'll want to be sure to read and understand the Terms of Service, particularly with respect to the prohibitions on spam.

Location: Split US centric properties off Location type?

2009-12-22T17:10:57.0000Z

There's no overhead to unused properties, so that's not an issue. The only potential issue is the "semantic clutter" in the schema, but for such a popular type, what's done is done. Adding future registry IDs someplace other than the main Location type is a possibility if it looks like there's going to be many of them, but I'm not familiar with how many of these registries there are. I know of Getty. Are there many others?

Location: UN/LOCODE and NUTS

2009-12-22T16:48:32.0013Z

Certain classes of UN/LOCODE are included implicitly (like the IATA airport codes), but I don't believe there's any place where all of the information is included.

Location: Split US centric properties off Location type?

2009-12-22T13:33:24.0013Z

You're right that breaking existing applications would be bad. My main thought is that probably just a small percentage of all Locations do have any of those IDs and thus having that property on every Location does not seem to be accurate. Actually, these IDs seem to be exclusive: If a Location has an USBG name or a GNIS ID, it cannot have a GEOnet feature ID - and vice versa.

Location: Split US centric properties off Location type?

2009-12-22T12:47:15.0000Z

What value is going to be gained by moving the existing properties, remembering that this will break every application using them?

General Support: Can I export delicious bookmarks to Freebase?

2009-12-22T12:29:50.0000Z

This blog post introduced the CommonTag concept, which basically allows you to have Freebase topics as a tag in a standardized way. It also mentions Zigtag and Faviki, which basically seem to be something like del.icio.us with CommonTag. Maybe these websites can help you to solve your problem, if you're willing to start over and to teach your users how to use them?

Location: Split US centric properties off Location type?

2009-12-22T11:01:59.0018Z

What do you think of splitting the properties

off the Location type to one or more new types? If I understood the property descriptions correctly, these properties are US centric in one way or another and if every local name/id authority in the world was added to the Location type, it would be bloated.

Location: UN/LOCODE and NUTS

2009-12-22T10:56:43.0000Z

Is there any location type that holds information about the UN/LOCODE and/or the NUTS information of a location?

Football League Season: Include Sports League Season

2009-12-22T10:45:42.0013Z

I did the same for Handball League Season which I basically modelled after Football League Season a few months ago. Did not regret my choice so far: The type does not have a lot of properties itself, but it allowed me to add Sports Team Season Records to some handball teams. :)

Sports Association: Team/League association not dated

2009-12-22T10:39:10.0006Z

I don't get why the Sports Association type suggests that a sports team is a member of a league and that does not change. If it would change, all historical data of a league participation would be gone once the Freebase topic is brought up-to-date, and I don't think that's a good idea. :)

The way the Football League Participation and Football League Season are modeled makes much more sense - to me - which is why I originally modelled Handball League Season and Handball League Participation after those types.

Even though these custom built types for each sport seem to work relatively well right now, it seems to me that it our data would be better for a lot of things if there was a generic "Sports League Participation" type in the commons and if the Sports League Season refered to the sports league and the participating teams somehow.

I would really like to see the sports commons a bit more flexible than they ae right now. The sports leagues that I know of have some relegation and promotion to higher leagues etc., so a team's place in a league is not ever set in stone. :)

Computer Emulator: Add emulated peripherals?

2009-12-22T04:32:18.0005Z

Column: Unsyndicated columns?

2009-12-22T02:31:23.0000Z

Wait. Back up. The whole "collection of columns" idea was in response to your first reply to this thread, wherein you resisted the notion of creating topics for each individual column, and instead just "start with the column topic, give it a year range, and link that CVT to the collection", as you put it. My thought was that we could use one model for that approach, which would allow people to connect columns to collections without needing to go ahead and create topics for each individual instance of the column; we could still use the existing publication model alongside that to enable people who want to link individual columns. Yes? Or did I completely misunderstand your previous post?

Column: Unsyndicated columns?

2009-12-22T01:02:26.0009Z

Publication can be used to model a collection of columns where each column article is a published work. For columns that don't have individual titles, I'm guessing the topic name would follow TV talk show episodic name format -- like "January 10, 1996". After all, usually it's not the column in its entirety that's collected, but individual pieces, sometimes within a date range, sometimes grouped by subject matter.

Can you elaborate on how exactly "collection of columns" would link the collection to its content? It's not clear to me what the alternative would be.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-22T00:56:58.0009Z

There is an app currently used as a demo that depends on some specific schema, www.popstra.com. There are no developer resources to make changes to the app at this time.

So backward compatibility is still important for the owner of popstra and he doesn't want the sww_base properties (heat...) to be public. The plan was for those properties to be locked.

The provenance issue was a core requirement. Unfortunately the schema development was based on a non-freebase repository and time did not permit creating new schema when the switch was made to freebase.

It seems like the real issue is whether anyone plans to add lots of new data. The Popstra base has not been actively tended to for months. Does someone want to give it the love it deserves? If so, I'm sure the original creator of popstra would accommodate.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-22T00:56:09.0021Z

There is an app currently used as a demo that depends on some specific schema, www.popstra.com. There are no developer resources to make changes to the app at this time.

So backward compatibility is still important for the owner of popstra and he doesn't want the sww_base properties (heat...) to be public. The plan was for those properties to be locked.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-22T00:55:47.0025Z

There is an app currently used as a demo that depends on some specific schema, www.popstra.com. There are no developer resources to make changes to the app at this time.

So backward compatibility is still important for the owner of popstra and he doesn't want the sww_base properties (heat...) to be public. The plan was for those properties to be locked.

Music: Thematic catalogs

2009-12-21T22:38:15.0012Z

The changes under consideration are discussed on our wiki, here. I'm not sure how much of what you're considering would affect or be affected by them (although certainly just creating a schema for thematic catalogs shouldn't affect anything).

Music: Thematic catalogs

2009-12-21T22:14:34.0023Z

A further thought: if big changes to the music structures are planned for the next few months should I hold off doing this?

Music: Thematic catalogs

2009-12-21T22:13:27.0002Z

I think anyone who creates a thematic catalog is almost certainly, in fact, a musicologist but most musicologists do not create catalogs, so I'll change 'musicologist' in the schema to 'thematic catalog creator'.

'Thematic Catalog creator' could then be usefully picked up by anyone who wants to build a base of musicologists.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-21T21:59:18.0009Z

I second both of Phil's concerns. The first is addressable by simply moving the properties we want to keep to the commons Celebrity type, and leaving the rest on the Popstra one; as long as we kept the old property keys, legacy queries should still work. The second is rather more problematic, since the properties in question are on CVTs. If backward-compatibility is needed with the original Popstra model, I'm not sure what to do with those properties.

There's also another issue that many of the properties denormalize properties on other types: religion (although the primary religion property [on the Person type] is not date-mediated) and endorsements for sure, and possibly some others. These would have to be migrated, but again, if backward-compatibility is important, it may be problematic.

Column: Unsyndicated columns?

2009-12-21T21:25:08.0030Z

So your suggestion is that the instance of Column itself would be the Published Work? My issue with that is that a long-running column may generate multiple books. For atomic works (stories, essays, poems, etc.), all Publication instances containing that work represent publications of the same single work. However, with Columns, you can't make that assertion -- each Book publication is going to be a completely different subset of articles. It's similar to saying that a Literary Series should be a Published Work if part of the series is collected in book form.

Column: Unsyndicated columns?

2009-12-21T20:47:34.0006Z

Why would we need a new type for "collection of columns"? Publication is used to model collection of short stories today. I don't see why it wouldn't work for columns.

Column: Unsyndicated columns?

2009-12-21T20:12:55.0013Z

Great. Here's where I think we stand with promoting this schema to the commons:

Figure out how to model both syndicated and unsyndicated columns
Create a type for Collection of Columns
Document types and properties.

Did I miss anything?

Music: Thematic catalogs

2009-12-21T20:09:58.0006Z

I second Phil's comment about musicologist. Most musicologists haven't created a thematic catalog, so it would seem a bit odd to have a type for musicologists with only one property which didn't related to the majority of them. (There are lots of commons types with properties that only apply to some of the instances, but those properties aren't typically the only property of the type.) In general, though, I think this would be a useful schema to have in the commons.

Computer Emulator: Add emulated peripherals?

2009-12-21T12:26:26.0013Z

One thing it would be nice to be able to model for some work I'm doing is which peripherals are emulated by each emulator - any objections to adding "Peripherals emulated" and "Peripheral classes emulated" to this type, and probably the reverse properties as well?

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-20T23:00:59.0006Z

-1 for promoting this in its current form. There's the basis of a good schema here, but this isn't it yet. I raised a number of issues in this mail, none of which seem to have been addressed. More generally:

There seem to be a mixture of application-specific properties ("heat", "interest") and general properties in the types - promoting the latter makes sense, but I think the former should stay out of the commons.
Do we want to go down the route of having every property being a CVT with source and date? I think everyone acknowledges data provenance is an issue, but I'm not convinced this is the right solution.

Music: Thematic catalogs

2009-12-20T22:40:29.0000Z

One more thought: is someone who creates a thematic catalog automatically a musicologist? (I have no opinion on this due to a complete lack of knowing what I'm talking about). If not, references to "musicologist" should probably become "thematic catalog creator".

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-20T22:36:44.0013Z

I support it as well, as I originally created the commons celebrity type and acknowledge the clear superiority of the popstra ones.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-20T22:36:31.0000Z

I support it as well, as I originally created the commons celebrity type and acknowledge the clear superiority of the popstra ones.

Celebrity: Promote /popstr/celebrity to Commons?

2009-12-20T22:29:54.0014Z

+1 to this happening?

Column: Unsyndicated columns?

2009-12-19T13:19:37.0030Z

current column type does not specify type of publication; so magazine, newspaper, and newsletter columns would fit in current schema.

+1 to new type "collection of columns." Stephen Jay Gould's books that began as columns in Natural History come to mind.

Music: Thematic catalogs

2009-12-19T10:14:13.0018Z

If you haven't already, it's definitely worth reading the Commons page on the wiki. Generally, this looks good to me, but a few mostly nitpick comments:

Documentation: none of the properties of thematic catalog are documented. Musicologist isn't documented at all.
Documentation part 2: the type description for thematic catalog doesn't really tell me anything that the name of the type doesn't. What is this type for? What sort of things should be typed as this type?
Musicologist should probably include /people/person.
Are we sure there are no thematic catalogs which refer to more than one composer?
Consider if any of the properties should be disambiguators.
I don't really see the value in having the underscore in the musicologist_s key.

Hope this helps!

Music: Thematic catalogs

2009-12-19T05:57:26.0037Z

I've built a base of thematic catalogs (for classical composers) http://www.freebase.com/type/schema/user/simonhill/default_domain/thematic_catalog

Does this belong in music commons and/or should there a reciprical link to it for composers?

I'd like to get reference to the database showing up under each composers - without having to have separate (duplicative) composer topics in my db.

I'd be grateful for any help or ideas.

Simon

Column: Unsyndicated columns?

2009-12-18T00:23:45.0013Z

This would additionally require a new type "collection of columns" or the like, which would have an included type of Book.

Column: Unsyndicated columns?

2009-12-18T00:22:24.0013Z

A property on the Column type for "book collection" or "collected in" would answer your use case. Reifying individual columns using the current publication model would answer mine. I see no reason both couldn't exist side-by-side.

Column: Unsyndicated columns?

2009-12-17T22:08:07.0005Z

I was just pondering how to link columns to collection of columns published as books. Must topics for individual columns be created, or can I just start with the column topic, give it a year range, and link that CVT to the collection? I can't imagine entering individual columns for Herb Caen, for example, whose 50+ year career produced columns at a frequency of 5-6 days a week, even if I could find and correlate that data. Besides, his columns are not reprinted verbatim but heavily edited to omit anything too newsy and rearranged for flow. Technically the books don't really contain the original columns.

Column: Unsyndicated columns?

2009-12-17T19:55:55.0005Z

Capturing non-newspaper columns is a good idea. Some columns don't really have regular authors, just a regular periodical (the New Yorker has a slew of these: Talk of the Town, Onward & Upward with the Arts, Shouts & Murmurs, etc.), which we should keep in mind as a use case.

One additional thought I had is that if someone wanted to create topics for instances of a column, they could type the Column as a Literary Series. Not suggesting it be included as an included type, since it's definitely going to be the minority case (although I wish it weren't -- I could have once saved myself a lot of time if someone had entered each one of JB Priestley's "Thoughts in the Wilderness" columns individually somewhere, and further entered which ones were collected in the book of the same name. I'm just saying.).

Football League Season: Include Sports League Season

2009-12-10T12:10:29.0013Z

I would like to propose the Sports League Season type to be an included type of Football League Season. This should integrate the soccer commons a bit more with the sports commons, and ensure that all football seasons are added to the sports commons.

I believe this should be a non-breaking change, so I'll do it in the next couple of days if there are no objections.

General Support: Can I export delicious bookmarks to Freebase?

2009-12-08T18:00:32.0013Z

I understand your general goal, but I'm having a hard time figuring out how tagging services will work in the example that you gave. A spreadsheet is definitely the most directly applicable approach, in my mind, but I see a couple of possibilities for tagging services.

If you use a service like Diigo that has a comment field, you could define a little meta language for describing attributes. e.g. Found: 1956 Owner: Rupert Murdoch etc...

This is flexible and powerful, but is completely free syntax with no tool support, so any errors won't get caught until you try and parse the information and find you can't understand it.

You could define a set of tags and meanings for their mappings so that a news web site that gets tagged with "Egypt" you interpret as meaning that they cover Egypt as geographic area of focus. You could extend this so that "hqEgypt" means headquartered in Egypt while "coverEgypt" means they cover Egypt, but this quickly explodes out of control (and is counter to how people expect the tags to work). The problem is that you basically trying to encode the column heading and cell value from your spreadsheet in a single tag. This only works well for a small universe of values (for example, your date founded example wouldn't fit very well like this).

It seems like a spreadsheet is a better fit for detailed data collection. Perhaps you could use a tiered approach with one set of people doing identification and basic categorization of sources with a smaller, more sophisticated followup team that use spreadsheets to capture the data (perhaps transcribed from a filled-in email template that you have people submit information via?).

I don't feel like I'm helping very much, but I don't think I know enough about conditions on the ground to be able to offer relevant advice.