[Data-modeling] Modeling Incompatible Types

[Vishal Talwar]

Is there a possibility that for some set of types T, we want to say that no
topic should have all of the types in T but may have some subset? I can't
actually think of any, but if there are such cases, they point to a
different interpretation of that property than a mutex (because in that
case, {t1, t2, t3} is not equivalent to {t1, t2} {t2, t3} {t1, t3}).
Vishal

On Sun, Nov 16, 2008 at 10:25 PM, Kurt Bollacker <kurt at metaweb.com> wrote:

>
> /data_world/incompatible_types is one of the oldest attempts at
> documenting type metadata.  Sadly, it is often forgotten, even when
> its use would be helpful.
>
> On Sun, Nov 16, 2008 at 10:31:06PM -0500, Shawn Simister wrote:
> > Sorry for the double post. I tried posting this to the Data World
> > discussions page but there was no response so I thought I'd try this
> > list instead.
> > The question concerns the type /data_world/incompatible_types. I'd like
> > to add some entries to assert that /business/company is incompatible
> > with the following types:
> >
> > /music/release
> > /music/artist
> > /music/song
> > /music/composition
> > /media_common/creative_work
> > /common/image
> > /cvg/computer_videogame
> > /computer/file_format
> > /computer/programming_language
> > /computer/software
> > /tv/tv_series_episode
> > /type/content
> >
> > But I'm not sure how to organize them. Should I try to fit as many types
> > per mutex as possible or group them by category or just add one mutex
> > per type? Any suggestions would be appreciated.
>
> Having more than 2 types in a mutex (incompatible_type) is a nice
> improvement in efficiency of representation, but not absolutely
> necessary.  Just create pairwise instances if that's easier for you.
>
> For example, it's clear that
>
>  /music/artist
>  /music/release
>  /computer/programming_language
>  /tv/tv_series_episode
>
> are obviously all incompatible, so you could put them in the same mutex.
>
> As a side comment, I'd say that /music/artist is not intuitively
> incompatible with /business/company, since some bands may be
> incorporated.
>
>                                                                Kurt :-)
>
>
>
>
> > Shawn
> > _______________________________________________
> > 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
>



-- 
:v
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freebase.com/pipermail/data-modeling/attachments/20081116/e1e30dde/attachment.htm