[Data-modeling] Architecture - Unrealized Design and suggested changes to the structure type
Kirrily Robert
kirrily at metaweb.com
Mon Dec 1 22:17:05 UTC 2008
I had some really broad thoughts on projects and project management
and how to model them a while back. I should try and mock that up and
post it here to see whether it resonates for people.
K.
On Dec 1, 2008, at 12:37 PM, brendan wrote:
> 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
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
--
Kirrily Robert
Freebase Community Director
kirrily at metaweb.com
http://freebase.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20081201/9738b22d/attachment-0001.htm
More information about the Data-modeling
mailing list