[Data-modeling] Architecture - Unrealized Design and suggested changes to the structure type

[brendan]

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.

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.

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.

Brendan

On Dec 1, 2008, at 10:54 AM, Robert Cook wrote:

> Hi Iain -
> On Nov 30, 2008, at 12:00 AM, Iain Sproat wrote:
>
>> Following architect Jørn Utzon's recent death I took time to expand  
>> his freebase topic.  However I came upon a problem with modelling  
>> his many unbuilt works - http://en.wikipedia.org/wiki/index.html?curid=37262#Architectural_works
>>
>> There seems to be an 'Unrealized design ' 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 'structure ' type which has  
>> an enumerated value of the following 'planned design',  
>> 'unrealized', 'under construction', 'built', 'demolished'?
>
> 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.
>
> I can add that enumeration to the structure type if nobody has a  
> strong objection.
>
> I was going to argue against adding "unrealized" to the enumeration,  
> but I see that we already have examples of such:
>   http://www.freebase.com/view/en/the_illinois
>
> 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.
>
>> In a similar note, I felt that the 'engineer ' and 'engineering  
>> firm ' type which currently sit in the Architecture commons  
>> precludes all but civil & structural engineers.  My idea is to  
>> further develop the engineering base (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 'structure ' type, and instead the 'structure' type include the  
>> 'engineering project ' type from the engineering base.
>
> 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.
>
> 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.
>
> 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.
>
> R
>
>> I would appreciate any constructive comments on my above  
>> suggestions, and also any help with the engineering base.
>>
>> Regards
>>
>> Iain (sprocketonline)
>>
>>
>> _______________________________________________
>> Data-modeling mailing list
>> Data-modeling at freebase.com
>> http://lists.freebase.com/mailman/listinfo/data-modeling
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20081201/69f1d62a/attachment.htm