Discussions on Data Modeling Guide

Hi, Mike. Take a look at the Dated Integer and similar types. That’s how I would do it, but the idea of storing a vector is interesting, too. That would get a bit complicated, as it would be more of a compound-compound value type; the vector would still need CVTs like Dated Integer in order to keep the time associated tightly with the value.

Thanks Chris, That does seem like the type for the purpose. I'm not a data modelling expert, and am very new to Freebase, but I've got a feeling that the strict item-of-type model doesn't neatly fit time series data. I think it's an important enough data structure to reconsider the framework. Perhaps time series should be handled in the same way as images. I don't imagine that every pixel in an image is an item of row/column/RGB_Value type. btw, I am developing a collaborative framework for statistical analysis of time series data (primarily), and would be keen to store the data in something like Freebase, so everyone could benefit. I'd be keen to discuss further with Metaweb. Regards, Mike

This is an interesting modeling problem, but I think in this particular case, an end-run is possible and even desirable. The type Synthesizer is really a kind of effective synonym for “electronic keyboard,” and I am not sure that synthesizing software should be made instances of that type.

To answer your broader question, though, there is not currently a way to merge two properties of two different types. We are looking at ways to infer values of a property from other ones, and you could then infer the synthesizer brand from the software manufacturer (or vice versa), so that queries could find instances easily, but hide one or the other from the UI. It’s an interesting problem, but I’m not sure when. among all the other interesting problems, we’ll come up with a solution to it.

This is really cool problem. Software really causes some interesting problems because it is non-physical.

To me, a software synthesizer really has more in common in a fundamental way with software than a physical synthesizer. At the same time, you would like to query over all synthesizers, including software ones, to find matches.

The problem you're describing is really more of a cosmetic than a semantic one. Software:manufacturer and Synthesizer:brand are similar ideas but really are about something different (strangely, I think that they should both be called brand -- in this case, it's good they aren't or the confusion would be even worse.)

I agree with Chris that a synthesizer is really a physical object and so not appropriate in this case. I do see your need to use the properties of synthesizer for your new type. Currently we don't have "property borrowing" which would allow you to appropriate semantics from the existing Synthesizer type.

Without this property borrowing, there is nothing in freebase that says the properties in Synthesizer and Software Synthesizer are equivalent. The logic is then left to the application to figure that out, which is not ideal. When we have property borrowing, this should be possible, but that will take a couple more months at least.

Ed, I'm not sure I understand your questions exactly. It appears that you created "PIF breeding distribution code" as a Type, and the codes in this category as Topics of this Type. On the other hand, you created "PIF population size code" as a Topic belonging to the "Classification System" type. So they're not two types, but one topic, one type, and that's why they are presented differently -- you're comparing apples and oranges (or, more appropriately, an apple [topic] and an orange crate [type]).

I think another way to approach the schema may be to create all the code classes (PIF breeding distribution code, PIF population size code, etc.) each as a type, with "Classification System" as an included type. Would that serve your purpose?

Inccidentally, when I typed "PIF breeding distribution code" into Google, it responded with, "Did you mean PIG breeding distribution code?" Thought you'd get a kick out of that.

Thanks Faye,

After playing around with this a little more I see that you are correct that size code was not a type initially.  I created the type as a separate step with the same name as the topic. However, I still can't find a topic page for the distribution code type.

Yes, creating all the types first within my "Classification system" type seems to solve my problem. However, what if I want to make a new type in a Domain. How do I state that his type is also a topic?

Faye, I've pasted your response to this last question that was also posted on my dueling modeling list post.

As for question 3: To designate a topic page as about a type or domain, add type "Type/domain equivalent topic" to the topic. You'll then have the properties "Equivalent Domain" and "Equivalent Type" to fill out for the topic. Currently this will only work if you're an admin for the type/domain you want to designate as "equivalent", so it should work for you.

Sometimes, though, the need to add structured information to a type can be met by modeling the schema a different way, instead of attaching an "equivalent" topic to the type. Something to consider.

Ed, by default types don't have a "topic" page. The idea is that a type is a catalog and defines the structure for the items (topics) in it, whereas the topics in the type carry the real information.

However, you can do the following: 1) create a topic to hold more information about a type. 2) Add the type "type/domain equivalent topic" to that topic you just created. 3) Fill out properties "Equivalent Domain" or "Equivalent Type" to that topic to point back to your type or domain.

But if you consistently find the need to want to label a type as an item belonging to another type, then it's time to take another look at your schema.

Going through the Equivalent Domain or Type route works but it's kind of messy. The topics have the extra properties associated with them, etc. It seems that it may be better for me to create a type in each domain that is used to create new types in that domain if I want them also to have associated topics.  

The reason I want to consistently label a type as an item belonging to another type is because I tend to classify things within hierarchies. For example, PIF breeding distribution code is a kind of PIF code which is a kind of Classification code. This hierarchy goes one way. For example, a Land cover code is a Classification code but is not a PIF code. However, if I want a list of Classification codes regardless of whether or not they are PIF or Land cover codes then I can do that by filtering on the Classification code type. This is very important for organizing my topics and types and creating types made out of "type modules" like your "Published work" type. It will also be very useful for keeping my queries simple when I start making them.

You have Classification code as an included type for a PIF code type, so that should give you the behavior that by default very topic typed PIF code will also be co-typed Classification code.

What kind of information do you need to record for a type that you need a topic page? Can you give me an example?

If you look at the PIF breeding distribution code topic page, there is a description, a quote that describes how the ranks were quantified, and a link to the publication that provided the quote and description. All of these properties are best attributed to the code type rather than to all the individual code topics of that type.

Compare that page to the PIF population size code page.  It also contains a description, quote and link but it does not contain the Equivalent Domain and Equivalent Type links.

For each of these two Type/Topic equivalents I had to create both the type and topic individually and then reciprocate the all the topics within each type. It seems like there are way too many steps needed to do this and way too many opportunities for typos or other errors. I understand that these reciprocal links need to be explicitly stated, but it seems that the topic page should be automatically created and linked for each standard type (maybe not as often for enumerated types and very rarely for CVTs). Also, is there any reason why you would NOT want to reciprocate a topic back to the type from which it was created? If no, then it seems that the reciprocation should be automated as part of the UI and not left up to the modeler unless they wanted to change, add or remove the type.  

Hi tantang,

 The site went through a redesign a while ago and some of the navigation items across the top changed names.  For instance, "Developers" became "Apps", roughly speaking.  So if you're looking at something that uses the old navigation scheme, it's probably just outdated.  Where did you see it?  I can see about getting the relevant docs/screenshots/whatever updated if necessary.

Thanks,skud.I saw it in the video of intrdction to freebase.

Hi tantang, as Kirrily mentioned, "Developers" became "Apps". In addition, "Types" became "Data", and to get to your profile, you only need to click on your user name where on top of the page where it says, "Welcome back, tantang", or use url: http://www.freebase.com/view/user.

BTW, it looks like you're experimenting with data modeling. May I suggest using sandbox.freebase.com for testing? Its data is wiped and sync'd to production data every Monday or so, making it a great place for experimenting without worrying about leaving test data behind. You can read more about using sandbox here.

Oops, the absolute sandbox url is http://sandbox.freebase.com. 

Hi Alex,

Welcome to Freebase.  Contains and Contained by properties are meant to be used to show spatial relationships between different locations; for example, the relationship of a city to a state.  It is really not meant to be used to be used to demonstrate the relationship of a location with a retail establishment.  To contain retail establishments within a location is not a task that we would expect end users to be able to maintain - think of how many Starbucks or McDonalds are in one city alone!

I see you've already checked out the Retail location type.  Retail location has an included property Address, which expects a Mailing Address CVT.  As an example, you could write a query to show you all restaurants in West Yorkshire:

{
  "query" : [
    {
      "/business/retail_location/address" : {
        "street_address" : null,
        "street_address_2" : null,
        "citytown" : null, 
        "state_province_region" : "West Yorkshire",
        "postal_code" : null       
      },
      "id" : null,
      "name" : null,
      "type" : "/dining/restaurant"
    }
  ]
}

Because address is a property of the included type /business/retail_location, I used the fully qualified property name in my query.

Hope this helps.

Thanks Cheunger, that does make a lot more sence now I'm getting used to this model. 

I have a question about your query though. When I Read that query it returns the Nando's restaurants in the West Yorkshire area as intended, but also includes the Nando's Parent Comany node/topic (Business Chain type), even though the parent company node doesn't have the /business/retail_location/address type we're matching on.

Is this normal behaviour? Does the parent node some how inherit the address form it's linked retail_location?

I'm afraid I might have led you slightly astray with my last query.  Below I've written another query you can use.  I would also take a look at this <a href="http://www.freebase.com/view/?id=%239202a8c04000641f8000000004198613">Modeling Guide for Restaurants</a>.  It's a guideline on how to model single-location restaurants vs. business chains such as Nando's.

You'll want to change your query to something like this:

<pre>
{
  "query" : [
    {
      "address" : {
        "citytown" : null,
        "postal_code" : null,
        "state_province_region" : "West Yorkshire",
        "street_address" : null,
        "street_address_2" : null
      },
      "id" : null,
      "name" : null,
      "type" : "/business/retail_location"
    }
  ]
}
</pre>

Ugh, sorry about that - the HTML didn't format.  The link to the modeling guide is:

  http://www.freebase.com/view/?id=%239202a8c04000641f8000000004198613

and ignore the pre tags in the query. 

Create a new type to hold the information you want and then co-type the person's topic page with that type. It will add the property so you can fill it in. However, try to use existing Freebase common types whenever possible so you don't reinvent the wheel.

Hi Jason,

 You're correct that something like "Vacation home" may be too idiosyncratic to be useful as a property publicly.  However, that does not mean you can't create a type in your own private domain with a that property and co-type concepts with your private type!

This thread and the one below on "favorite things" begs a discussion (and standards?) for when to employ common types vs. user published and unpublished types.

My "Classification system" type might offer an example to start the discussion. It is a container to hold various classification systems and type them with universal properties. For example, all classification systems have classes.

In your Favorites example, you could create a "Jason's Favorite" type that could have a property of "Jason's favorite thing". Add the "Dog Breed" topic to your list of Favorite things and then fill in the "Jasons favorite thing" property for the breed topic. A problem with this approach is that Jason's, Ed's and everyone else's favorite lists muddy up the category topic  pages. 

One way to do it would be to add a property on the types that you expect to have overlapping topics called something like "equivalent or overlapping topics", with an expected type of /common/topic. You wouldn't get the automatic reciprocation this way, unfortunately.  It's not very elegant, I admit.

Another option is to insert a phylogeny pattern somewhere. (E.g., something like a parent/child or superclass/subclass relationship.) So for your land cover classifications, you could have a third, generic "land cover" type that would operate as an included type on your two existing cover types. This type would have properties "includes land covers" and "land covers included" ("includes" might be the wrong term, here, I'm not sure). So "Upland forest" would include both "deciduous forest" and "coniferous forest". Your queries could then walk up or down the tree to find equivalences. 

Thanks Jeff, I think this approach will work very well. Using your suggestion and the location type as a model, I'm inlcuding properties such as "Completely contains (class)", "Completely contained by (class)", and "Overlaps with (class)". This approach is actually very similar to how NatureServe is classifying Ecological systems. Their classification system is hierarchical structured but classes at each level often overlap because they may only differ by proportions of the same plant species. 

Hi solphusion,

 Good question - essentially, how many levels of containment should a location have?    The short answer is, roughly two levels of containment, but it doesn't hurt to have more.  That is, for a given location, the Contains and Contains By properties have the next 2 smaller and next 2 larger units of location, respectively.  For example, the German Federal State of North Rhine-Westphalia should contain all the cities within its jurisdiction, and be contained by Germany.  However, I also don't see Colonge, Germany being contained by World as a helpful containment.

One problem is once you get past the 2 levels of containment - an US example is, how do I know that San Francisco is in the United States?  In the US, the contaiment (from smallest to largest) is city -> county -> state -> region -> country.  If I look at California, it contains San Francisco, and is contained by the United States, but I would not be able to know that if I was looking at San Francisco.  Eventually, we hope to have transitivity in location, so it is easier to find out containment of a particular location.

Cheunger,

Isn't containment for a location automatically inherited? I mean, for San Francisco you can say that
SF ⊂ CA ⊂ USA ⊂ North America ⊂ Earth ... and so SF should only have CA as its container and CA should only have the USA as its container, etc.

If containment is disputed (e.g for Political reasons ) it might be right to have two containers of the same level but adding USA as a container of San Francisco seems redundant/confusing.

blixa,

 The short answer is that containment is not automatically inherited.  Right now, the "2 up, 2 down" levels of containment guideline, with it's redundancy and confusion, helps make up for the lack of transitive closure.  See this post for some other details. 

Oops, improper use of a contraction - it should be "...containment guideline, with its redundancy and confusion, helps make up for the lack...".

Properties are not dynamic in Freebase. The way administrative hierarchies work in Freebase is by use of the "contains" and "contained by" properties on the type "location". All administrative subdivisions should also be typed with their appropriate type. In the case of India, these would be Indian state, Indian union territory, Indian district, Indian division, and Indian sub-division (which, following the usage of the Indian census, should include areas variously known as sub-division, tahsil, C. D. block, circle, R. D. block, taluk, and commune panchayat, depending on which state they're in).

If more are needed for sub-subdivision levels, they can be created -- I modeled these largely off the Indian census data, with some input from Wikipedia.

"person" is another example of this.  There is a "person" type in freebase.  There is also a "person" topic (which references the wikipedia article on
person") 

 The way this is currently handled is: the topic and the type are two different objects in freebase.  The topic is marked as an instance of a type called: "type/domain equivalent topic". This may seem a little odd but I think it's a way of clearly separating types from topics.

 Whether a topic, such as "Talaria" merits having an equivalent type is up for debate. We're talking about a mythical, arguably fictional thing that is probably only talked about as a concept, i.e. no one talks about *that* particular Talaria and how fine it was.  What would be an "instance" of talaria? I don't think there's any practical value of having such a type.

So, by this criteria, having a type "Sandal" is practical: instances could include consumer products (e.g. "The Birkenstock Arizona") And the "Sandal" type could be included by another type "Huaraches" referring to the subset of sandals found mostly in Mexico.

I'm sorry, I'm not helping with the root question "how could we get WordNet data in freebase"

Maybe alternatively create a 'WordNet entry' type, add that to the topics that are listed in WordNet and add such fields as 'hypernyms', 'hyponyms', 'meronyms', et cetera.

Or is that too specific to one data source?

I think that Freebase’s internationalization makes a difference here; to me, words should be distinct from concepts, but connected. For instance, the topic for dog has names in multiple languages (page down in the Explore view), and not everything that WordNet will have to say about “dog” will apply to the organism. I would make a type for Word (with a “Language” property) or for English Word to use for WordNet topics, and link the Word instances with the topics that they describe in English.

The hypernym/hyponym relationships apply not only to the words but to the topics themselves (e.g., that “dog” is a hyponym of “animal” implies that a dog is a kind of animal), and that information could be applied to the topics themselves, but the words have, IMO, an independent existence.

WordNet keeps separate relationships for each of the senses. Still, it'd be hard to map those, maybe.

Well, sure, “dog” the animal and ”dog” to secure a hatch have different WordNet entries. But there are still things that one can say about “dog,” the word referring to the animal, that aren’t true of “chien” (and vice versa), while that is not the case for dog/chien/hund/etc. as a concept, especially etymological observations.

This is a project I find exciting, but it (like most interesting projects) is hard to do right. 

I don't think anyone has made an attempt to model collegiate (or other school-level) athletics. Feel free to take a stab at it. There are a lot of types in the sports domain that could probably be pulled in as included types.

Nevermind, I was not checking the "use as disambiguation" checkmark.

Welcome to Freebase, Stephanie! It’s good to see you’ve been exploring and making some useful contributions.

1) We’ve actually been trying to avoid the “List of Foo” topics from Wikipedia; in general, we feel that they are a compensation for Wikipedia’s lack of structure. The Freebase type system generally provides a better way to organize that kind of information.

For example, if there were a Hot Air Balloon Festival type (which there will be as soon as any Freebase user is interested enough in hot air ballooning to create it), then the List of Hot Air Balloon Festivals would simply be the list of instances of that type. Even better, it could be sorted or queried by any of the properties that the type provides, such as date or location.

The Billboard list is a more interesting case. That’s not really just a list; it’s also an assertion of a special status of its members as distinguished from their peers, a kind of award or recognition. There is currently some interesting discussion on how to approach list-type awards (such as the AFI 100 list of films or the Fortune 500), which would be applicable here. I don’t know what the right answer is right now.

2) Any Musical Track could be co-typed as an Award-Winning Work and the awards thus attached. That said, I am leery of mass imports of Musical Tracks (as opposed to Songs or Compositions) because reconciliation is so very difficult. If this area interests you, I strongly recommend joining the Music Modeling Interest Group and/or the data-modeling mailing list.

Thanks for your suggestions and questions!

Hey,
Thanks so much for your reply. I guess the real question has to do with importing this information. I have a group of people who are able to start adding data to freebase, but we want to do bulk imports instead of doing it by hand. I guess this is essentially adding topics of a certain type or adding properties to an existing topic in bulk. Can you tell me who i should ask about how to format this and upload?

Thanks!

This is as good a place as any to ask.

Through the UI, there is a list import option when viewing any type, or any property that allows more than one value. That allows users to paste or upload a tab-delimited list and walks them through the reconciliation process.

The API can also be used for scripted uploads, although in that case either topics need to be pre-reconciled, or the queries need to be sufficiently well-structured to make it probable that duplicates will not be created.

Reconciliation—the notion that there is one Freebase topic for any singular real-world concept—is both Freebase’s power and its challenge, and we spend a lot of time working on tools to make that process easier. (There should be a blog post about the reconciliation service very soon, for instance..)

If a user publishes a type, other users will see it; if the user does not, other users will not.

We will continue to evolve more view filters as Freebase grows, but right now, that’s pretty much it.

Commenting on Toby’s type was a good start; you may also want to comment on the user’s profile itself to bring it to his attention.

The general model is that a user (you, Toby, or anyone else) prototypes a type in their private domain and experiments with it a bit. Then the user publishes it and invites other users to try it out. Then the user requests that the administrators of an appropriate domain promote the type, or requests creation of a new domain if the subject is complicated enough.

I recommend the data modeling mailing list for these collaborations. 

There may be something I am missing: it looks like you’ve answered your own question! (“If you want to change that name, and you have the necessary permissions, you can change it on that other type.”) I’ll try to break it down, though.

When looking at the schema for a type, you can only edit the properties on that type. The “linked in as” is the name of the reciprocal property on some other type, so you can’t edit that directly; you must visit the other type to change it.

To create a “linked in as,” a reciprocal property, is very simple. Once you have a property from one type to another, go visit the schema for that other type. At the bottom of the schema editor, you will see “Suggested Properties”; these are un-reciprocated incoming properties from other types. If you edit the name of one of those, you have not only picked up a new property with its “linked in as” already set, you have now changed the “linked in as” on the other type.

Please note that the schema editor is being redesigned, so the details of this process (though not the fundamental concepts) may change.

Now, if you don’t have the rights to edit the other type, you’re out of luck. Let’s say you make a private type called Hater with a property called “People Hated” that expects Person. Unless you’re an administrator of the People domain, you can’t reciprocate that property as “Hated By.” And that’s just as well; we don’t want everyone on the system to be able to edit all the types, which is why we have the administrator system in place. If you think that known by whom a person is hated is critical information to the Freebase community, you can ask the People administrators to reciprocate the property, or even to promote your Hater type into their domain.

Does that help? 

You can't add a property to a type unless you are an administrator of that type. 

It looks like interior artwork is attributed through the issue's Contents property, which links to the comic_story_printing CVT, which links to comic_book_story, which already has properties for penciler and other artists. This was probably done because a single issue might have multiple stories illustrated by multiple artists.

So, it is already possible to add the penciler of interior artwork but you must do that through comic book story instead of issue. It would be nice though if you also linked story to issue through printing by attributing all those properties too.

Thanks for the reply. It makes sense now, although it would be more discoverable if the comic_book_issue itself also had the Penciler property which could contain all the values from individual stories contained in the issue.

Is it possible to become a type administrator or can only the freebase employees do this? What's the best way to contact an admin with a suggestion?

I'm pretty sure anyone can become an admin for a type with the permission of another admin for that type, although there are different levels of admin now. Your best bet is to start a discussion in the domain or type of interest. You can also add a discussion to one or more of the domain administrator's user name(s) making the request. Otherwise they might not know you are interested. This here is a very general discussion area that may not be watched by the comic book domain administrators.

Hi wellstone,

 FYI - most locations include the type statistical region which has a property for population (ECT of dated integer).  If you look at the earth, the value for 2007 has already been inputted.

Hip thanks for the heads up....