[mb-style] NGS RFC: Make works not be filed under an artist(Was: Spurrious works)

[Lukáš Lalinský]

On Wed, Apr 7, 2010 at 1:58 PM,  <autodave at davesmey.com> wrote:
>> Whatever you call them - Works, LKWorks, etc - the fact remains that
>> they would be Work entities.  The mere fact that you can so clearly
>> separate >LKWorks from Works is why I'm saying they shouldn't be
>> mixed together as the same thing.  I would have no problem with a
>> "songThingie" entity, >which links to each performance by a specific
>> artist of a specific work.  What I do have a problem with, however,
>> is overloading Works with that >entity.  Additionally, I think any
>> recording has a 'songThingie', but (as we talked about elsewhere), I
>> don't think every recording has a work.  As two >separate entities,
>> it makes sense.  All lumped into the Work entity, it's quite clear
>> that there's two completely different concepts being forced to >share
>> the same dataspace.
>
> Basic question - are works/thingies going to be freely recursable?
>  Can I create work1 that is parent to work2 and work3?
>
> Even as composition objects, we might want this, for different versions
> of "the same" piece.
>
> I agree that on the level of guidelines and UI, we'll want to very
> clearly differentiate between Works & LKWorks and whatever other
> meta-class we might come up with.
>
> But the most elegant datastructure might be an abstract, recursable
> object with as few fields as possible, and everything added to it by
> AR.  (The only essential fields might be "name" and "what kind of
> thing am I.")

This is what NGS works were meant to represent. The UI will not make
the distinction between work types in the initial NGS release, but the
plan is *exactly* what you are describing. You can use ARs to create
any structure you want. There will be per-type textual attributes for
works (for representing data that are not links, for ISWC makes only
sense for some types), but not in the initial release.

Lukas