<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">The unrealized design type was supposed to be a "included type" with the structure type. It's use is not prevalent. I'm ok with the enumeration idea. <div><br></div><div>There are a number of challenges we need face in evolving from what we are calling structures in freebase to something more complex that can reflect the full range of interesting information. I believe, a "project" is an abstract thing that is not the same as the structure (though I suppose we've conflated the two). The project could include information about the zoning/legal status, the various organizations contributing to the project in various ways. To further complicate things, the project might include multiple structures and landscape/site design, all attributable to different individuals or firms. Moreover, each of those firms have their own concept of a project relating to their contribution.</div><div><br></div><div>I think we started with the simple structure type with the idea that representing physical things/spaces, their location, their physical attributes, the key people responsible was the highest priority. I've been reluctant to go further for fear of getting bogged down in modeling complex stuff without having interesting data available, to justify the cost. Perhaps there is way we could approach this incrementally without sacrificing simplicity too much.</div><div><br></div><div>Brendan</div><div><br><div><div><div>On Dec 1, 2008, at 10:54 AM, Robert Cook wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hi Iain - <br><div><div>On Nov 30, 2008, at 12:00 AM, Iain Sproat wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Following architect <span class="Apple-style-span" style="font-family: '-webkit-sans-serif'; line-height: 19px; "><a href="http://www.freebase.com/view/guid/9202a8c04000641f800000000004a42f">Jørn Utzon</a>'s recent death I took time to expand his freebase topic. However I came upon a problem with modelling his many unbuilt works - <a href="http://en.wikipedia.org/wiki/index.html?curid=37262#Architectural_works">http://en.wikipedia.org/wiki/index.html?curid=37262#Architectural_works</a></span><div> <span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;">There seems to be an '<a href="http://www.freebase.com/type/schema/architecture/unrealized_design?domain=/architecture">Unrealized design</a> ' type in the architectural domain, but this has no properties and thus no way to link back to the designer. Perhaps it would be better to scrap this type and instead have a 'status' property in the '<a href="http://www.freebase.com/type/schema/architecture/structure">structure</a> ' type which has an enumerated value of the following '<span class="Apple-style-span" style="font-style: italic;">planned design</span>', '<span class="Apple-style-span" style="font-style: italic;">unrealized</span>', '<span class="Apple-style-span" style="font-style: italic;">under construction</span>', '<span class="Apple-style-span" style="font-style: italic;">built</span>', '<span class="Apple-style-span" style="font-style: italic;">demolished</span>'?</span></div></div></blockquote><div><br></div><div>I do like your idea of adding an enumeration to the structure type that explicitly defines the status of a structure. It would be a denormalization, to be sure, as one could determine the status of a demolished building using the existing "destruction date" and/or "destroyed by" properties. But it's also important for people to encode that a structure is demolished/destroyed even if the date or method of destruction is not known.</div><div><br></div><div>I can add that enumeration to the structure type if nobody has a strong objection.</div><div><br></div><div>I was going to argue against adding "unrealized" to the enumeration, but I see that we already have examples of such:</div><div> <a href="http://www.freebase.com/view/en/the_illinois">http://www.freebase.com/view/en/the_illinois</a></div><div><br></div><div>My only question is how to distinguish between buildable, but unbuilt and pure fantasy. The example above is somewhere between, but as it's the design of an architect of many real buildings, it probably deserves to be "unrealized". I assume this would allow all submissions for the World Trade Center replacement buildings to be typed as unrealized structures as well. I'm curious what others think.</div><div><br></div><blockquote type="cite"><div dir="ltr"><div><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">In a similar note, I felt that the '<a href="http://www.freebase.com/type/schema/architecture/engineer">engineer</a> ' and '<a href="http://www.freebase.com/type/schema/architecture/engineering_firm">engineering firm</a> ' type which currently sit in the Architecture commons precludes all but civil & structural engineers. My idea is to further develop the <a href="http://engineering.freebase.com/">engineering base</a> (although currently structural/civil engineering heavy, I plan to include all kinds of engineers - mechanical, chemical, electrical, electronic and perhaps even data/information engineers!). I think it would be great if the 'engineer' and 'engineering firm' properties could be removed from the '<a href="http://www.freebase.com/type/schema/architecture/structure">structure</a> ' type, and instead the 'structure' type include the '<a href="http://www.freebase.com/view/base/engineering/engineering_project">engineering project</a> ' type from the engineering base.</span></div></div></blockquote><div><br></div><div>My personal caveat about bases is that they work best when you scope them smaller. Part of this is because of the current limitations in the UI (which really only scale to a few views -- we will be working on that), but more importantly, bases succeed better when the scope is achievable by a small group of people and the "edges" of the base are within sight. </div><div><br></div><div>Also, I think that various engineering disciplines are distinct enough that it would cause confusion to blur those semantics in the data model. Engineering a building or a dam is very different than engineering a rocket engine. There is commonality, to be sure, but there is a cost to lumping here. Abstract types and properties, although they help machine interpretation for very general use cases, come at the cost of human readability. Typically people understand the data model from their narrower scope and are daunted by abstraction.</div><div><br></div><div>In Freebase, semantics are developed not necessarily from top-down or bottom-up, but more middle-up. That is, there data models are typically well-thought out for a particular domain. If there becomes a need to encode semantic equivalence among multiple domains, that can be done by (to be defined) meta-structures on the types and properties themselves. </div><div><br></div><div>R</div><div><br></div><blockquote type="cite"><div dir="ltr"><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;">I would appreciate any constructive comments on my above suggestions, and also any help with the engineering base.</span></div> <div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;">Regards</span></div> <div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;">Iain (sprocketonline)</span></div> <div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;"><br></span></div><div><span class="Apple-style-span" style="font-family: -webkit-sans-serif; line-height: 19px;"><br></span></div> </div> _______________________________________________<br>Data-modeling mailing list<br><a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br><a href="http://lists.freebase.com/mailman/listinfo/data-modeling">http://lists.freebase.com/mailman/listinfo/data-modeling</a><br></blockquote></div><br></div>_______________________________________________<br>Data-modeling mailing list<br><a href="mailto:Data-modeling@freebase.com">Data-modeling@freebase.com</a><br>http://lists.freebase.com/mailman/listinfo/data-modeling<br></blockquote></div><br></div></div></body></html>