[Data-modeling] proposed change to two types: /architecture/architectural_firm and /architecture/engineering_firm

[Jack Park]

By and large, it may be that a mapping framework could be conceived
that seeks to keep all schema somehow mapped to emerging "standards"
(whatever those are). Certainly seems worth thinking out loud about.

Jack

On Thu, Nov 20, 2008 at 4:20 PM, brendan <brendan at metaweb.com> wrote:
> In this particular case, the architecture domain, not at all (I can't
> speak for other freebase domains). This one has grown somewhat
> organically as new data and linkages arrived in freebase.  I'd like to
> think this schema is simple and sane enough that we could migrate or
> map to another schema in the future.  I'd be interested to hear about
> alternatives out there.
>
> brendan
>
> On Nov 20, 2008, at 4:01 PM, Jack Park wrote:
>
>> If I may step in and ask a really naive question (newbie alert), to
>> what extent do the emerging microformat and other standardized
>> vocabularies, e.g. FOAF, SIOC, and so forth, affect schema design?
>>
>> Thanks in advance.
>> Jack
>>
>> On Thu, Nov 20, 2008 at 3:21 PM, brendan <brendan at metaweb.com> wrote:
>>> This is in progress... gave you all 4 months to object :)
>>>
>>> -  /architecture/architecture_firm/partner will not be removed, just
>>> hidden in the UI so users won't add more values.
>>> - /architecture/architecture_firm has an included type /business/
>>> employer
>>> - all  /architecture/architecture_firm/partner values have been
>>> copied
>>> over to /business/employer/employees
>>>
>>> Next up the same basic pattern for /architecture/engineering_firm
>>>
>>> Note: the saved views really helped here (yes I did all the data
>>> migration through the freebase.com UI!)
>>>
>>> http://www.freebase.com/view/user/brendan/default_domain/views/populated_firms
>>>
>>> the filter specifies firms where "Firm Partners" is not empty
>>>
>>> brendan
>>>
>>> On Jul 14, 2008, at 5:58 PM, brendan wrote:
>>>
>>>> I'd like to draw some cleaner lines here.
>>>>
>>>> Both of these types have properties for "partners". It's been
>>>> pointed
>>>> out that this is probably asserting too much and lacks the time span
>>>> of their tenure.  It just seems more sensible to remove these
>>>> properties and specify a "suggested type"  /business/employer which
>>>> has a property that can encompass these "facts" in a more general
>>>> way.  There's very little data involved, so I can handle migrating
>>>> the
>>>> links.
>>>>
>>>> brendan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>