The reason is that MQL doesn't enforce any types. There is no requirement that the thing connected by the 'state' property be a state. i.e. in freebase the type system is not normative. Its perfectly OK to put a person in that clause, should that make sense to you.
The rationale for doing this is the requirement of schema migration. We have a "loose" typing system. What started out as a set of us_state types might end up as a set of us_regions_area types (example contrived) and while the expected type of the property would change (ECT) there is no requirement that all the data would be brought into line immediately or in fact ever. What is true is that the object would still remain the thing we call Delaware, no matter what happened to the schema over time.
The expected type is just that, only an expectation of what kind of thing is to be found in that clause. This also explains why when you write something in a subclause you have to specify the type also, you might think that MQL could do it for you (and perhaps it should).
This is an excerpt from a developers@freebase message.
Search Help Center
Discussions
There are no conversations on this topic. Would you like to start one?
Start the Discussion »- Building Bases
- Creating Schemas
-
Developing Applications
- An Introduction to Freebase Application Development
- Playing in the Sandbox
- Freebase Programming Libraries and Tools
- Data Dump FAQ
- Using the Query Editor
- The Complete Metaweb Query Language (MQL) Reference Guide
- MQL Cheatsheet
- The MQL Cookbook
- Freebase API Reference
- Application Developer Tips
- The Acre Hosted Development Environment
- Introduction to the Metaweb Javascript Template Language (MJT)
- Freebase Community
