> -----Original Message-----
> From: Code for Libraries [mailto:[log in to unmask]] On Behalf Of Richard Wallis
> Sent: Tuesday, December 13, 2011 3:16 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Namespace management, was Models of MARC in RDF
> 
> On 13 December 2011 22:17, Peter Noerr <[log in to unmask]> wrote:
> 
> > I agree with Karen below that a record seems more bounded and static,
> > whereas a description varies according to need. And that is the
> > distinction I was trying to get at: that the item stored in some
> > database is everything unique about that entity - and is static, until
> > some data actually changes, whereas the description is built at run
> > time for the user and may contain some data from the item record, and
> > some aggregated from other, linked, item records. The records all have
> > long term existence in databases and the like, whereas the description
> > is a view of all that stored data appropriate for the moment. It will
> > only be stored as a processing intermediate result (as a record, since
> > its contents are now fixed), and not long term, since it would be
> > broken up to bits of entity data and stored in a distributed linked
> > fashion (much like, as I understand it, the BL did when reading MARC
> > records and storing them as entity updates.)
> >
> 
> Yes.  However those descriptions have the potential to be as permanent as the records that they were
> derived from.  As in the BL's case where the RDF is stored, published and queried in [Talis]
> Kasabi.com:
> http://kasabi.com/dataset/british-national-bibliography-bnb
>

I would argue that they are stored permanently as multiple records holding the data about each of the individual entities derived from the original single MARC record. In my mind (for this discussion) anything that is stored is a record. It may be a single agglutinative record such as MARC, or the same data may be split amongst records for the work, the author, the subjects, the physical instance, the referenced people, etc. But the data for each of those is stored in a record unique to that entity (or in records for other entities linked to that entity), so the whole data set of attributes get spread around as fields in various records about various entities - and the links between them, let us not forget the very real importance of the links for carrying data. 

When a user wants to view the information about this title, then a description is assembled from all the stored records and presented to the user. It is, almost by definition (as I am viewing this), an ephemeral view (a virtual record - one which is not stored complete anywhere) for this user. If the user stores this record in a store using the same mechanisms and data model, then the constituent data values will be dispersed to their entity records again. (If the user wants to process the record, then it may well be stored as a whole, since it contains all the information needed for whatever the current task is, and the processed record may be discarded or stored permanently again in a linked data net as data values in various entity records within that model. Or it may be stored whole in an old fashioned "record" oriented database.)

 
> 
> >
> > Having said all that, I don't like the term "description" as it
> > carries a lot of baggage, as do all the other terms. But I'm stuck for another one.
> >
> 
> Me too.  I'm still searching searching for a budget airline term - no baggage!

How about something based on South West - where bags fly free! Though I can't make any sort of acronym starting with "SW"!
> 
> ~Richard.
> 
> --
> Richard Wallis
> Technology Evangelist, Talis
> http://consulting.talis.com
> Tel: +44 (0)7767 886 005
> 
> Linkedin: http://www.linkedin.com/in/richardwallis
> Skype: richard.wallis1
> Twitter: @rjw
> IM: [log in to unmask]