Re: vocabs, metadata set, datasets

All:


The presentation Tom is thinking of is
athttp://gordondunsire.com/pubs/pres/EvolCatRec.ppt
 
Feel free to point to it, or cannibalise it, or quote from it (it has notes).
 
A definition of "record" from the MADS/RDF Vocabulary Description document
(http://www.loc.gov/standards/mads/rdf/):
 
"Used throughout the current document to describe the compilation of facts about
something or, especially in the case of the present document and topic, the
collection of triple statements about an authoritative or variant term (such as
a subject or name heading)."
 
Which generalises to: "The compilation of facts about something, or the
collection of triple statements about something."
 
See also the Background section of the BibData use case cluster
(http://www.w3.org/2005/Incubator/lld/wiki/Cluster_BibData): "... bibliographic
record, a set of data elements describing the content and characteristics of an
information object manufactured for human consumption.". Which generalises to "A
set of data elements describing something." - but are we developing a definition
of "record" within the bibliographic context, or just generally?
 
Cheers
 
Gordon
 

On 18 January 2011 at 13:03 Thomas Baker <tbaker@tbaker.de> wrote:

> On Tue, Jan 18, 2011 at 01:17:04PM +0100, Mark van Assem wrote:
> > Should we ask Gordon to draft an entry on Records?
>
> Gordon could perhaps point us to one of his "deconstruct the
> record" presentations (I hope I'm not mischaracterizing
> the message...).  Karen also has a notion of "open records" (and
> "recombinant data") that could fit here too.
>
> Tom
>
>
>
> > On 17/01/2011 21:24, Thomas Baker wrote:
> > >On Mon, Jan 17, 2011 at 10:06:34AM -0800, Karen Coyle wrote:
> > >>>It works well enough for drawing an analogy, but I wouldn't
> > >>>want to paper over the problem, especially the bit about
> > >>>records being about "one entity (e.g. a book)" -- which is
> > >>>in my opinion simply wrong because a typical catalog record,
> > >>>for example, contains descriptive elements not just about a
> > >>>book, but its author, publisher, etc.
> > >>
> > >>I think we've gone into the "focus" area again here. A library
> > >>record is designed to provide a complete enough description of a
> > >>book (or piece of music, or map, etc.) to fulfill two functions:
> > >>
> > >>1) identification of a resource owned or licensed by a library
> > >>2) user access to that resource
> > >>
> > >>The inclusion of related things like authors, places of publication,
> > >>etc. are all with the focus of the thing being cataloged, not as a
> > >>way to describe those related things. Authors are described in their
> > >>own records (name authority records), but only the identifier for
> > >>the author record is included in the bibliographic record. (It just
> > >>so happens that the identifier used today is a text string that
> > >>looks a whole lot like a name.) Thus FRBR and FRAD as separate views
> > >>of bibliographic data.
> > >>
> > >>The *wholeness* of the record is important because it represents a
> > >>description of the thing that is a complete description. While
> > >>individual statements may be usable in other contexts, the library
> > >>function of bibliographic description will always require a
> > >>particular set of statements (at a minimum). I believe we will
> > >>continue to call this set of statements a "record" for a fairly long
> > >>time.
> > >
> > >I agree with you on this, and I think it is important enough
> > >that we should say it clearly like this -- somewhere... maybe
> > >in an entry on "Records".  But it should perhaps also be
> > >acknowledged that the Linked Data space does not have a
> > >universally agreed way to express a bounded record.  This is
> > >a gap that DCAM, for example, tried to address.  The RDF
> > >community has spoken of "named graphs" for a number of years,
> > >but the term is still ambiguous (does it refer to quoted
> > >graphs? graph literals? URIs for graphs?  graph stores?).
> > >Standards-based support for provenance in Linked Data will
> > >depend on what is now referred to as "support for multiple
> > >graphs and graph stores".  For the glossary, we should avoid
> > >going into this sort of detail but this is such an important
> > >difference in paradigm that we should try to characterize
> > >the issues in a few sentences somewhere.
> > >
> > >Tom
> > >
>
> --
> Tom Baker <tbaker@tbaker.de>
>