Discussions on jeff

Mah! But I filled out the property hints, can I get a bronze star at least?

Heh, filling out descriptions.

Just came across this. I'd definitely support a business category property on business location.

It would be useful to model whether a business location operated by a company is a cafe or their offices.

I agree, we need a closing date for business location.

However, I think business location might be better off including 'dated location' type?

ah no! it's to remain HAS-A location http://markmail.org/message/db76hw73tdof6upm?q=freebase+list:com.freebase.data-modeling+date:200911+from:%22Jeff+Prucher%22&page=1

Scrap the request for dated location!

Could we get a /business/business_location/closing_date though?

I agree somewhat. Funny, I just posted my Need to expand beyond just followers. And THEN, I read your post here. LOL. However your suggestion is fairly comprehensive. I was thinking more along the lines of what I suggested, since not all followers necessarily are orthodox (strict followers), so a quick selection drop down might be a better approach and cover a broader use? I thinking on just the basics as shown in this table ... http://asiarecipe.com/religion.html

X - prohibited or strongly discouraged A - avoided by the most devout R - some restrictions regarding types of foods or when foods are eaten O - permitted, but may be avoided at some observances

Anyone else ? Let's get this merged somehow. I need it somewhat and I'm sure others do as well. Put it to a vote.

i  agree that employer should be un-cotyped.

check out the 'organisation types' and you'll find most of them are not employers http://www.freebase.com/view/organization/organization_type

cheers

great idea ft.Conference series has a sponsorship property, but this should be optionally on conference event aswell.

im an admin on this (poorly admined) base, and will cotype 'Sponsored Recipient' and hide our sponsor property unless someone says i shouldnt.

Thanks for all your replies, as hinted by cheunger, I used the sponsor, sponsorship and sponsored recipient types to assert to assert the sponsorship relationship between OSCON2009 and a few companies.

I thought it had to be a fairly tedious affair to perform the appropriate co-typing and property filling, but  the impressive fluidity of the UI made it quite an enjoyable experience.

Kudos to the Freebase team. 

I agree that this probably should be more than one topic, but I'm not sure what the best way to organize them is.  The idiom of combined library & library system seems to be used a lot for small one library "library systems,"  so splitting them all would be a fair amount of work for not a lot of benefit. 

Colloquial usage by people tends to consider the library institution and the library structure to be one and the same, but it's really the same situation as museums where you can have a one room library in a building or libraries can move from building to building.

It's a modeling fidelity vs user confusion/work tradeoff that I don't feel strongly about one way or another, so I guess we should get Jeff or one of the Library admins to weigh in or make the call.

The choices are:

1. One topic
2. Three topics
3. Library System/Library + Building
4. Library System + Building/Library

I definitely support splitting the libraries from the library systems. I think the type is (or was) documented in such a way that the main branch of each system should be combined with the system itself, but that just seems confusing to me.

The building vs. thing the building is used for is a perennial problem, and not one we've ever really solved.  What I'm leaning towards now would be to cotype the library (museum, embassy, etc.) with the building/building complex where appropriate (since as Tom points out there are lots of cases where the library/museum/whatnot might only take up part of a building). And also with the clear expectation that these combined topics will have to sometimes be split when the building user moves to a new location (which can result in the confusing situation where the now vacated building is still known as the library building, even though it now serves some other purpose). I guess that'd be a long-winded way of saying #4.

(I'm drawn to #2 for fidelity, but I also reconize that it would border on being unusable.)

#2 would be the best, but is overkill for most libraries.

#3 wouldn't work well for library systems which have multiple libraries (any national library, or large university library), and I agree with jeff that #4 would relate well with everyday use.

And another edge case - my library used to be in a van which would tour around the region.  So no building involved at all :)

I should have clarified that my support of #3 was only for the library systems with a single library.

I'm happy with #4 as long as we're consistent about it.

@rybesh,  I've already been working on some generic types which should work with any religion.  I've called the type Religious Jurisdiction.  Let me know if you have any comments on the type.

@jeff - where did we get to with promoting these types to the commons?

It's sitting in my personal domain at the moment, so will still be considered a 'draft'.

I've now created a base http://religiousjurisdiction.freebase.com/

Let me know if it still doesn't work. 

It's getting promoted: https://bugs.freebase.com/browse/DA-838

Thanks for pointing the need for the reciprocation.  Hopefully the reciprocation will happen once the promotion is done.

Actually, I'm going to delay this -- the migration is too complex to do piecemeal. I've posted a query to the developers list about changing the expected type of /religious_organization_leadership/role to "Religious Leadership Title". Once we get buy-in for that, we can do the migration.

I'll reciprocate the religious organization property of jurisdiction, though, so that people can better use the type in the mean time.

wibble

Thanks cheunger 

Thanks skud.

As much as I'd like to go crazy with my new powers and move everything to the commons, I'll hold back as I'd like some critical review of the types I mashed together in the association football base earlier today.

Well, since you asked... :)   Bear in mind that I know exactly zilch about association football, other than which three English teams contain swear words in their names (which is what you learn when Billy Bragg is your main entree into the sport).

I notice that there is no direct relationship between players and teams (only via squad or match), and that in the case of Manchester United, you've co-typed it as both a squad and a team, which seems confusing based on the type descriptions.

Should soccer field include sports arena?

For goals, I think the disambiguator "team" is ambiguous -- at a glance it's not clear whether that's the player's team or the team the goal is credited to.

A soccer league does not seem to contain any teams.

Why is a soccer league also a soccer competition?

Soccer competition's property "seasons" expects "Event" rather than Soccer Soccer competion season.

Speaking of soccer competition season, the "matches" property should probably be reciprocated on the Match type.

But overall this is a very impressive schema!

Maybe add attendance to the soccer match type?

If possible, it'd be great if these types could inherit properly from the existing sports events/sports league championship events .. 

i.e. a soccer match (is a) sports event (is an) event .. a soccer championship event (is a) sports league championship event (is a sports event) (is an) event ..and so on ..

I'd mainly like this to reduce data duplication across types, and to enable querying across sub-types i.e. give me all the sports events held at Wembley in 2008 (although I suppose this is possible at the moment, but there is some duplication of data required i.e. location, date/time etc)

Just to add: 

The "sports league championship" type naming is probably misleading but the schema does fairly accurately describe all football cup events (Essentially the FA cup is a league championship for the FA associated teams, and the 1999 FA Cup Final was for the 2008-2009 FA Cup Season)  

The biggest difference for football I can see is in the multi-format competitions (although these are similar to american sports which the sports event types seem to have been created for) where you start with a league format and then a set of play off matches to arrive at a single winner i.e. world cup, euros, champions league

>I notice that there is no direct relationship between players and teams (only via squad or match) 

I've added a time-mediated property soccer player tenure.

 >and that in the case of Manchester United, you've co-typed it as both a squad and a team, which seems confusing based on the type descriptions. 

Now fixed, I've split the squad from the team.

 >Should soccer field include sports arena? 

now typed with sports facility.

>For goals, I think the disambiguator "team" is ambiguous

 now called "point awarded to"

>A soccer league does not seem to contain any teams.

I've created soccer league participation which is time-mediated using seasons instead of dates. 

>Why is a soccer league also a soccer competition?

This was where I was having issues.  I'm trying to get my head around the Sports commons and also get some abstract inheritance in. I was trying to make league competitions different from cup competitions, and possibly different from multi-format competitions - yet all have a common inheritance from soccer competition.

>Soccer competition's property "seasons" expects "Event" rather than Soccer Soccer competion season.

fixed this. 

>Speaking of soccer competition season, the "matches" property should probably be reciprocated on the Match type.

now reciprocated. 

 >If possible, it'd be great if these types could inherit properly from the existing sports events/sports league championship events .. 

absolutely, my problem is that I'm not too familiar with the sports commons. But if you could point out which types to include, I'll update the schema.  I've done soccer match now.

I've also added a schema for player transfers and loans. 

All my types are still in association football, and I'd appreciate any further comments on the types.  If we feel some of the types/properties are OK I will start replicating them in the soccer commons.  (with the plan to eventually move everything over and delete association football).

I'm planning to move the schema from association football over the next few days.

If anyone has further comments or improvements to the schema, please let me know.

Job done!  The schema is now up and running in the soccer commons.

Hopefully I got everything from football association across (I purposefully left out squads and competition season types as I think they're a bit flaky), but let me know if there's something wrong. 

Ideas for the next feature are welcome :)

yes. agree here.

there are many types of barcode systems thpough, so maybe it belongs in a seperate type?, which this type could eventually cotype.

i've got my hands on a big database of upc codes....

as long as this schema gets some +1's i'll upload it to this type this week.

This is a cool idea. I was talking with Robert a little while back, and he's actually identified four different semantic patterns that use this schema design (that is, of types that have two properties that expect each other, there are four distinct relationships these represent). 

1. Phylogeny: basically a hierarchical classification -- each topic is a member of a sub- or super-category. Organism classification is probably the canonical example.

2. Parent-child: each topic is begotten by (or begets) the other topics. The TV Episode spin-offs property is a non-biological example. (Organism is the other biological example.)

3. Sequence: you've already identified this

4. Containment: I can't think of any besides Location, but that doesn't mean they're not out there.

I tend to use "phylogeny" loosely when I'm talking about schemata to mean "two properties on a type that expect each other", since in terms of actual design there is no difference -- only in the ways humans interpret the patterns.

@ed, thanks for the example I've added it to the pattern.  I've also renamed peer to sibling and added an alias.

@jeff Thanks for the input, I confused parent-child and phylogeny.  I've made a new parent child type and renamed properties in phylogeny. 

I'm still slightly unsure about the definitions, particularly the difference between phylogeny, parent/child and containment, so I've tried to define them in stricter terms using graph theory concepts:

1. Phylogeny - It is a forest/directed acyclic graph.  I'm still slightly confused about how it is used in freebase - it is a self reciprocating parent/child relationship. e.g. organism classification to organism classification.  If it the property links two different types, it would be a parent/child.  Also, if the property linking to the parent is unique, it wouldn't allow union between trees so isn't a forest graph, and is just a tree graph - therefore a containment pattern.
2. Parent/Child - A directed acyclic graph/forest where topics are vertices and properties edges.  Given my guess that a phylogeny is a parent/child between one type, this pattern is different by being between two types.  i.e. the parent is a different type from the child.  e.g. book to book edition.
3. Sequence - an acyclic path graph
4. Containment - In set theory, A is a proper subset of B.  And would be a tree in graph theory.  This would be a self reciprocating property, otherwise it is a parent/child pattern.
5. Sibling - graphs between topics of the same type, with a definition of some sort of equality between linked topics.  I was going to suggest it be a complete graph based on the /people/siblings, but realised that wouldn't necessarily work for step families or /influence_node/peers.

I think this makes sense, and if these concepts are OK I'll update the descriptions on the pattern CVTs.

Given the graph theory rules, it would be possible to run a bot and identify topics for data gardening, or identify types/properties which follow these patterns based on their current use in freebase.

my definition of phlogeny being distinct from a parent/child purely based on whether a property is self-reciprocated on the same type, or is reciprocated on a different type doesn't feel right.

Under that definition it means that the relationship between /people/person/parents and /people/person/children is a phylogeny rather than a parent/child relationship....

Not intuitive, but perhaps logically OK?

Otherwise the seperation between phylogeny and parent-child patterns would have to be based entirely on whether the topic is an abstract concept e.g. organism classification, or is a real object e.g. person.  And that's a whole other rabbit hole.

gaah! *head explodes* 

Note that I didn't make up these distinctions, so I accept no credit or blame for them. :)

Re phylogeny vs. parent-child: it does seem to fall into abstract vs. concrete, doesn't it?  I think there is a logical difference between the relationship of a partent to a child and a genus to a species, however: a genus is a category that comprises one or more species; a parent is not a category, and does not comprise any children. To take this away from people, the "spin-off/spun off from" properties of Company are a parent/child pattern, but the "parent company/subsidiary companies" properties are a phylogeny (although in this case, a date-mediated one).

Note that species are also proper subsets of genuses, so I don't think that that can be the distinguishing factor between phylogeny and containment.

Properties linking two different types are an interesting point: these can follow the same semantic patterns as any of the ones listed above, but are inherently limited in number of steps, rather than open-ended, which is what we've largely been discussing here.  (So Adaptation/Adapted Work is a parent/child relationship; Country/Administrative Division is containment; etc.)

properties of two different types -> I've tweaked the phylogeny, parent/child and containment types so they can have 2 different types (one for the parent type, and one for the child type).  If a type is self-reciprocating, the same type would appear in both properties.

phylogeny vs parent/child ->  Agreed phylogeny is for abstract categories, parent/child for the concrete.  both super & sub* of a phylogeny are abstract categories/sets.

 phylogeny and containment ->  if phylogeny is for abstract categories which can contain other abstract categories, then containment is for the concrete/physical which can contain other concrete/physical?  e.g. location/location or building complex/building.

* BTW I'm using super/sub in place of parent/child as a way of differentiating when speaking about phylogeny.

As the properties on phylogeny, parent/child and containment are now all the same (parent type, parent->child property, child type, child->parent property); I'm tempted to normalise and just have one type for all three patterns, but include an additional property called "pattern variation".

This property would allow for differentiation between the patterns by selecting phylogeny, parent/child or containment from an enumeration.