Freebase: Discussion about Automated Merge

Pia Fajelagutan: Real Name

2009-12-25T18:14:11.0013Z

The surname might be wrong, By the way. is it spelled like that?

Pia Fajelagutan: Real Name

2009-12-25T18:13:41.0006Z

Is that Pia Fajelagutan's real name? Simply that? No other aliases either? I was finding it hard to get more info on her. Please verify.

Musical Release: Barcode & Catalog Number

2009-12-25T08:31:41.0013Z

Thanks Tom for this explanation.

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-25T08:31:41.0013Z

Thanks Tom for this explanation.

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T23:24:13.0000Z

CVT = "compound value type"

If you're familiar with modeling in UML, it correlates to a UML Association Class. If you're not familiar with UML, it's basically a link + associated data. Rather than saying

CD --> ownedBy --> Phil

it says

CD --> ownedBy (fromDate, toDate) --> Phil.

In actual fact, at the most primitive level, it's just a set of nodes and arcs in the graph, but it's useful to think of this particular "clump" of nodes as a single object or link with attributes.

Musical Release: Barcode & Catalog Number

2009-12-24T23:24:13.0000Z

CVT = "compound value type"

If you're familiar with modeling in UML, it correlates to a UML Association Class. If you're not familiar with UML, it's basically a link + associated data. Rather than saying

CD --> ownedBy --> Phil

it says

CD --> ownedBy (fromDate, toDate) --> Phil.

In actual fact, at the most primitive level, it's just a set of nodes and arcs in the graph, but it's useful to think of this particular "clump" of nodes as a single object or link with attributes.

Musical Release: Barcode & Catalog Number

2009-12-24T23:22:13.0006Z

CVT = "compound value type"

If you're familiar with modeling in UML, it correlates to a UML Association Class. If you're not familiar with UML, it's basically a link + associated data. Rather than saying

CD --> ownedBy --> Phil

it says

CD --> ownedBy (fromDate, toDate) --> Phil.

In actual fact, at the most primitive level, it's just a set of nodes and arcs in the graph, but it's useful to think of this particular "clump" of nodes as a single object or link with attributes.

Musical Release: Barcode & Catalog Number

2009-12-24T23:22:13.0006Z

CVT = "compound value type"

If you're familiar with modeling in UML, it correlates to a UML Association Class. If you're not familiar with UML, it's basically a link + associated data. Rather than saying

CD --> ownedBy --> Phil

it says

CD --> ownedBy (fromDate, toDate) --> Phil.

In actual fact, at the most primitive level, it's just a set of nodes and arcs in the graph, but it's useful to think of this particular "clump" of nodes as a single object or link with attributes.

Musical Release: Barcode & Catalog Number

2009-12-24T20:46:16.0005Z

Yes Chris, I agree with you.

Nevertheless, I don't understand what a CVT means. Could you explain, please?

Your idea of ratings and review is very good but I don't know how to implement such 'personal' fields ...

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T20:46:16.0005Z

Yes Chris, I agree with you.

Nevertheless, I don't understand what a CVT means. Could you explain, please?

Your idea of ratings and review is very good but I don't know how to implement such 'personal' fields ...

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T19:16:17.0013Z

I’m not going to say whether Freebase should be used for this. I think Freebase should be used for whatever the community successfully uses it. If I were to include personal ownership, I would have a release ownership type, a CVT that correlates a person with a release and things like purchase date. Otherwise, what does it mean to see that To Venus and Back was purchased on 1999-10-20, 2002-05-30, and 2005-07-16? To see that Jane purchased it on 1999-10-20, Bill purchased it on 2002-05-30, and Joe purchased it on 2005-07-16 is arguably a little more useful. Even more useful, users could associate ratings or reviews with their ownership, as well; it would be a way to provide some access control via whatever app is creating those ownership nodes.

Musical Release: Barcode & Catalog Number

2009-12-24T19:16:17.0013Z

Musical Release: Barcode & Catalog Number

2009-12-24T17:47:58.0006Z

Dear Chris,

I admit that my type 'Musical Release (Details)' is redundant. Actually this type is a kind of test and will probably be erased in a near future.

You've noticed that I've included a 'Puchases Date' field because I would like to enter individual ownership information but I realize that FreeBase may not be intended for this purpose. What would be the best way to handle this 'Purchase Date' information?

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T17:47:58.0006Z

Dear Chris,

I admit that my type 'Musical Release (Details)' is redundant. Actually this type is a kind of test and will probably be erased in a near future.

Regards

Phil.B

Muriel Brassler: Murial Brassler Alive and Well!

2009-12-24T17:08:48.0000Z

Muriel Brassler is not a fictional character. She is known as Muriel Emory, by marriage. Brassler was her maiden name. I have met her a few times, since I know one of her children. She is a very refined and elegante woman. She is presently living in Monroe County, Pennsylvania, at a Senior Citizens Apartment Complex. She used to live in Hemlock Farms Development in Hawley, PA. You can see a picture of her at the following website: http://www.hollowaypages.com/welles.htm

Hope this will clear up some misunderstanding.

Musical Release: Barcode & Catalog Number

2009-12-24T17:05:06.0000Z

I hadn’t noticed the Barcode type. That would be good. However, rather than linking your own Musical Release (details) to Barcode and then co-typing Musical Releases , I think it would be better to co-type Musical Releases as Barcoded Items. In general, your Musical Release (details) seems largely redundant. Original Release Date is present already. What does “Year of this Edition” gain? And “Purchase Date” confuses me; are you proposing to enter individual ownership information? The MusicBrainz ID is already present, as well, via a key, and AMG and Discogs links are best handled as keys into a namespace.

Musical Release: Barcode & Catalog Number

2009-12-24T17:05:06.0000Z

Musical Release: Barcode & Catalog Number

2009-12-24T16:54:31.0013Z

Hi Crism,

and thank you very much for pointing me to the location of the catalog number. Now I understand the goal of the 'Local Release' topic.

I notice that Barcode already exist in FreeBase : http://www.freebase.com/type/schema/base/barcode/barcode This type allow to link an item (i.e. a Musical Release) to a Barcode.

Once again, many thanks for helping me on this topic.

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T16:54:31.0013Z

Hi Crism,

and thank you very much for pointing me to the location of the catalog number. Now I understand the goal of the 'Local Release' topic.

I notice that Barcode already exist in FreeBase : http://www.freebase.com/type/schema/base/barcode/barcode This type allow to link an item (i.e. a Musical Release) to a Barcode.

Once again, many thanks for helping me on this topic.

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T14:53:19.0005Z

First, I misspoke above; we do have the catalog number, just not the barcode. Moreover, we have the date and place of Release Events. That really should be enough. See To Venus and Back for an example. I don’t believe we imported this information from MusicBrainz initially.

Musical Release: Barcode & Catalog Number

2009-12-24T14:53:19.0005Z

Musical Release: Barcode & Catalog Number

2009-12-24T14:19:05.0013Z

Yes you're right, the release date could be one way to distinguish 2 releases, but the how to differentiate a UK release and a French release which should be different but released a the same date ?

I think that, as it is implemented at MusicBrainz, the only way to differentiate 2 releases is to specify BarCode, Catalog Number and even Release Date.

Regards

Phil.B

Musical Release: Barcode & Catalog Number

2009-12-24T14:19:05.0013Z

Yes you're right, the release date could be one way to distinguish 2 releases, but the how to differentiate a UK release and a French release which should be different but released a the same date ?

I think that, as it is implemented at MusicBrainz, the only way to differentiate 2 releases is to specify BarCode, Catalog Number and even Release Date.

Regards

Phil.B

Developer Support: Query Freebase with SPARQL

2009-12-23T12:20:21.0000Z

I would like to query Freebase from my application using a SPARQL query. What would be the best way to do that?

Kevin Rose: Primary Type

2009-12-23T07:51:19.0006Z

In my mind he's associated with Digg and, in general, Company Founder would trump TV Personality, but you're never going to keep everyone happy. Is Donald Trump a real estate developer, TV personality or serial groom? Probably depends on who you ask.

Kevin Rose: Primary Type

2009-12-23T01:37:47.0013Z

Hi,

The notable types algorithm is a work in progress, much of it depends on how well filled out the data is, what types are applied on a topic, and the interaction between types. The newest results that will be on production soon has Kevin Rose most notable as an "Audio Program Host." Is that more acceptable? Adding data to more notable types on a topic will help boost their notability.

Kevin Rose: Primary Type

2009-12-23T00:35:15.0013Z

It has his primary type as TV Personality which I think is flawed. How do we change the primary type that gets placed in the typeahead?

Column: Unsyndicated columns?

2009-12-22T23:21:32.0000Z

Ahhh, OK. +1 on the new type.

Column: Unsyndicated columns?

2009-12-22T23:21:32.0000Z

Ahhh, OK. +1 on the new type.

Christopher Jones: Delete - Wikipedia disambiguation page

2009-12-22T22:15:16.0013Z

Movie data has been moved to the actor. The remainder can be deleted.

Sports Association: Team/League association not dated

2009-12-22T19:17:33.0006Z

I agree -- adding a CVT to the relationship between any team and any league(s) would be a much better way to model this. I'll create a JIRA task for the proposal (DA-1020). This would be a major change, so we'll have to run it past the mailing lists.

Sports Association: Team/League association not dated

2009-12-22T19:17:33.0006Z

General Support: read only in app

2009-12-22T18:58:51.0013Z

Add details...

Location: UN/LOCODE and NUTS

2009-12-22T18:39:39.0013Z

Looking at the NUTS info, it looks like we'd need a new type "NUTS region" or the like -- the NUTS codes (at least for Europe) frequently don't correspond to actual administrative divisions of countries.

I'm tempted to say that UN/LOCODE should just go on Location, though -- it seems like a lot of different things (mostly cities and airports, I guess) can have them, but I'm only saying this based on about ten minutes looking at the UN/LOCODE data.

Location: UN/LOCODE and NUTS

2009-12-22T18:39:39.0013Z

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: 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?

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?

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. :)

Sports Association: Team/League association not dated

2009-12-22T10:39:10.0006Z

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-22T02:31:23.0000Z

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.

Column: Unsyndicated columns?

2009-12-22T01:02:26.0009Z

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.

Johann Sebastian Bach: Generalisation of Catalog DataBase

2009-12-21T21:25:20.0015Z

Hi Simon, I'm definitely interested in collaborating on catalogs of composers. I've not had any time to look at your work yet and I've been focused on studying the Bach catalogs -- I've been learning about the complexities around BWV, something that had seemed very simple to me. Over the vacation break, however, I hope to have more time to put into Bach + Freebase.

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-21T21:25:08.0030Z

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: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?

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.

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

Johann Sebastian Bach: Generalisation of Catalog DataBase

2009-12-19T05:39:14.0018Z

Hi I've developed thematic catalogs base to hold high-level details of the thematic catalogs of composers - inc. BWV, of course.

I'm just figuring out how to link it into existing types (composer/musicologist/etc.) and considering how to extend it to allow bases of composers works. IS this something you would be interested in collaborating on? Maybe we could generalize the existing BWV base somehow, and them make it available hold works by any composer with appropriate opus and/or catalog numbers. A suitably filtered view could be available for any composer - or interestingly e.g. lyricist (i.e. which composers composed to words by xxx and when!)

I would like to link into it from a Songbird (open source music player) add-on to provide titling/info display functionality and, eventually, maybe some sort of data feed from Songbird tracks.

I'm new to freebase so just finding my feet. I'm finding the structural stuff OK but am not sure how to fit into existing material!

Grateful for any thoughts etc.

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: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-18T00:22:24.0013Z

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-17T22:08:07.0005Z