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

[Jeff Prucher]

There are a couple bases that provide schema to map various Freebase types
and properties to various ontologies, which might be similar to what you
have in mind:
http://www.freebase.com/view/base/ontologies
http://www.freebase.com/view/base/vocabulary

Your original question is actually a very good one, and it's kind of hard to
answer. The short answer is probably "not much", although there are
definitely schemata where it's more true than others.  A lot of design is
directly influenced by what data is readily available, which means that
there are a lot of properties in Freebase that can be mapped directly to
Wikipedia templates (which I suppose are a vocabulary in their own right).
I've sometimes used an ontology as a check, to see if I've missed anything
(when I've known about one to look at, anyway!), and the publishing domain
was influenced by a whole lot of various things.  My general take is that,
in an ideal world, a schema should be at least broadly mappable to other
ontologies, but, because Freebase is pretty easily extensible, the work of
doing so is sometimes best left until there's a real, rather than
hypothetical, need for it.  

Jeff


> -----Original Message-----
> From: data-modeling-bounces at freebase.com 
> [mailto:data-modeling-bounces at freebase.com] On Behalf Of Jack Park
> Sent: Thursday, November 20, 2008 4:24 PM
> To: Freebase data modeling mailing list
> Subject: Re: [Data-modeling] proposed change to two 
> types:/architecture/architectural_firm and 
> /architecture/engineering_firm
> 
> 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/popul
> >>> ated_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
> >
> _______________________________________________
> Data-modeling mailing list
> Data-modeling at freebase.com
> http://lists.freebase.com/mailman/listinfo/data-modeling
>