LISTSERV mailing list manager LISTSERV 16.0

Help for BIBFRAME Archives


BIBFRAME Archives

BIBFRAME Archives


BIBFRAME@LISTSERV.LOC.GOV


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

BIBFRAME Home

BIBFRAME Home

BIBFRAME  August 2014

BIBFRAME August 2014

Subject:

Re: [Radical] Transcribed and Controlled Data

From:

Simeon Warner <[log in to unmask]>

Reply-To:

Bibliographic Framework Transition Initiative Forum <[log in to unmask]>

Date:

Fri, 1 Aug 2014 16:17:08 -0400

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (115 lines)

This is a great topic for a Friday afternoon!

I strongly agree with Karen that true separation of the human and 
semantic data would be a dangerous thing for them getting out of sync. 
Think of program code: comments next to methods are out of date often 
enough, separate documentation is usually pretty much uselessly out of 
date/sync (though I'm sure nobody on this list would be guilty ;-) ).

The "mix it up with appropriate technologies" option seems worthy of 
more consideration. But even then I'm left wondering whether multiple 
technology stacks make life easier or harder when one likely expects 
cataloging tools to support update of both halves of the data (along 
with great tools to semi-automagically suggest the structured form from 
the human form (and vice versa)). If downstream tools want just one half 
or the other then one can imagine simple filter tools to pick one or the 
other portion of the data.

2c,
Simeon


On 8/1/14 12:54 PM, Karen Coyle wrote:
> Thanks, Rob.  I have suggested both of these in emails in the past week,
> although perhaps they got lost in their threads. Taking them in reverse
> order:
>
> 2. OCLC is already doing suggestion #2 through its use of schema.org
> based on its MARC data. Obviously, a more "data friendly" set of data
> would make that more efficacious. If we had a "record" that allowed the
> storage of identifiers in concert with the display strings, then it
> would be easier to export markup that facilitates linking. I suppose
> BIBFRAME could have been that record, but it has taken a very different
> approach.
>
> 1. I've contemplated the "catalog 'record' as document" concept at
> various times. True separation of the display from the coded semantics
> strikes me as dangerous, for them getting out of sync. As with the #2
> option, there would need to be hooks between the display forms and the
> "data forms" so that some automated processes could exist that don't
> allow one to change without checking the other.
>
> In either case, I come to the conclusion that we COULD provide this
> radical view, but not with the models and records that we have today. So
> this would entail the development of a new model that supports the
> solution. I also have said that we probably cannot achieve this with the
> cataloging rules that we have today. Essentially, new rules would need
> to take into account the coordination between display and
> "data/semantics." The current cataloging rules are still overly involved
> in display and ignore machine processing functions to support retrieval,
> comparison, and data mining.
>
> kc
>
> On 8/1/14, 9:18 AM, Robert Sanderson wrote:
>>
>> Dear all,
>>
>> In my experience, RDF and Linked Data can do both presentation based
>> information (eg here is content to present directly to the user,
>> without semantics eg [1]) and it can do semantic, descriptive
>> information (here is a rich description of the resource, say a book or
>> annotation eg [2]) but both at once is very challenging without simply
>> repeating everything in a for-machines way and a for-humans way as per
>> the current titleStatement, providerStatement, and one assumes
>> authorStatement, subjectStatement, etc.
>>
>> Here are two radical ideas, for which the boat has probably long since
>> sailed, but I'll throw them out there regardless.
>>
>> 1. Don't try to mix them up.  Have two completely separate
>> descriptions, where one is intended for humans to read, and the other
>> is intended for machines to reason upon and search.  A machine will
>> only ever throw a transcribed string through to the user, so make it
>> easy for them to do that by separating the non-semantic information
>> from the semantic information, with links between them.
>>
>> 2.  Mix them up using the appropriate technology: HTML + RDFA.
>>  Instead of thinking about triples for everything, instead create the
>> HTML that you want the user to see.  Then annotate that HTML with RDFA
>> properties to add the semantics into the record (and really a record
>> now, not a graph).  This way there's only one record to maintain that
>> has both, but uses presentation technology for presenting things to
>> users, and semantic technology for enabling machines to understand the
>> information.
>>
>> Basically -- use the right tools for the job.  RDF has a hard time
>> representing transcriptions outside of non-semantic strings because it
>> was never intended to do that.  Order in RDF is a complete pain,
>> because a graph is inherently unordered, but there are very real use
>> cases that require order.  On the other hand, RDF is fantastic for
>> controlled data as that is precisely its intended usage.  We should
>> make the most appropriate use of the tools that we have available to
>> us, rather than treating everything as a nail.
>>
>> Best,
>>
>> Rob
>>
>> [1].  The IIIF Presentation API is focused on this approach of giving
>> information intended for a client to display, while still being useful
>> linked data by referencing existing semantic descriptions and
>> following REST and JSON-LD. http://iiif.io/api/presentation/2.0/
>> [2].  The Open Annotation work is a rich data model that provides
>> semantics for web annotation, but says almost nothing about
>> presentation. http://www.openannotation.org/spec/core/
>>
>>
>>
>> --
>> Rob Sanderson
>> Technology Collaboration Facilitator
>> Digital Library Systems and Services
>> Stanford, CA 94305
>

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

October 2019
September 2019
August 2019
July 2019
June 2019
May 2019
April 2019
March 2019
February 2019
January 2019
December 2018
November 2018
October 2018
September 2018
August 2018
July 2018
June 2018
May 2018
April 2018
March 2018
February 2018
January 2018
December 2017
November 2017
October 2017
September 2017
August 2017
July 2017
June 2017
May 2017
April 2017
March 2017
February 2017
January 2017
December 2016
November 2016
October 2016
September 2016
August 2016
July 2016
June 2016
May 2016
April 2016
March 2016
February 2016
January 2016
December 2015
November 2015
October 2015
September 2015
August 2015
July 2015
June 2015
May 2015
April 2015
March 2015
February 2015
January 2015
December 2014
November 2014
October 2014
September 2014
August 2014
July 2014
June 2014
May 2014
April 2014
March 2014
February 2014
January 2014
December 2013
November 2013
October 2013
September 2013
August 2013
July 2013
June 2013
May 2013
April 2013
March 2013
February 2013
January 2013
December 2012
November 2012
October 2012
September 2012
August 2012
July 2012
June 2012
May 2012
April 2012
March 2012
February 2012
January 2012
December 2011
November 2011
October 2011
September 2011
July 2011
June 2011

ATOM RSS1 RSS2



LISTSERV.LOC.GOV

CataList Email List Search Powered by the LISTSERV Email List Manager