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

[Robert Cook]

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

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