Print

Print


On 1/30/15 6:58 PM, Tim Thompson wrote:
> Karen,
>
> Aren't the semantics behind MARC just the semantics of card catalogs 
> and ISBD 
> <https://en.wikipedia.org/wiki/International_Standard_Bibliographic_Description>, 
> with its nine areas of bibliographic description? ISBD has already 
> been published by IFLA as a linked data vocabulary 
> (http://metadataregistry.org/schema/show/id/25.html)--although 
> <http://metadataregistry.org/schema/show/id/25.html%29--although>, 
> sadly, they left out the punctuation ;-)
>
> Tim
The semantics of MARC are funky because of the way that things like 
indicators interact with subfields in fields, etc. Take a look at my 
analysis and you'll understand.

MARC goes way beyond ISBD -- by far.

Note also that ISBD is deeply flawed. ISBD has its nine areas of 
description. Each area begins with ". -" Not all nine areas are required 
therefore you can have:

.- area 1
.- area 3
.- area 9

or

.- area 1
.- area 2
.- area 4

What a machine sees is:

.- area?
.- area?
.- area?

 From a data processing point of view, this is not helpful. There may be 
a way to determine which area you have, but the model does not clearly 
distinguish them. Human eyes and brains are needed.

kc



>
> --
> Tim A. Thompson
> Metadata Librarian (Spanish/Portuguese Specialty)
> Princeton University Library
>
> On Fri, Jan 30, 2015 at 9:01 PM, Young,Jeff (OR) <[log in to unmask] 
> <mailto:[log in to unmask]>> wrote:
>
>     What if it was two different vocabularies, rather than two
>     different levels of abstraction?
>
>     There is only one reality. A rose by any other name would smell as
>     sweet. :-)
>
>     Jeff
>
>
>
>     > On Jan 30, 2015, at 8:02 PM, Martynas Jusevičius
>     <[log in to unmask] <mailto:[log in to unmask]>> wrote:
>     >
>     > Karen,
>     >
>     > lets call those specifications BM (BIBFRAME MARC) and BLD (BIBFRAME
>     > Linked Data).
>     >
>     > What I meant is two different levels of abstractions, each with its
>     > own vocabulary and semantics. And a mapping between the two, for
>     which
>     > SPARQL would be really convenient.
>     >
>     > In the 2-tier approach, these are the main tasks:
>     > 1. convert MARC data to RDF at the syntax level (BM)
>     > 2. design semantically correct bibliographic Linked Data
>     structure (BLD)
>     > 3. define a mapping from BM to BLD
>     >
>     > So in that sense I don't think it is similar to profiles, as
>     profiles
>     > deal with a subset of properties, but they still come from the same
>     > vocabulary.
>     >
>     > A somewhat similar approach is W3C work on relational databases:
>     > 1. direct mapping to RDF: http://www.w3.org/TR/rdb-direct-mapping/
>     > 2. customizable declarative mapping to RDF:
>     http://www.w3.org/TR/r2rml/
>     >
>     >
>     > Martynas
>     > graphityhq.com <http://graphityhq.com>
>     >
>     >> On Fri, Jan 30, 2015 at 10:15 PM, Karen Coyle <[log in to unmask]
>     <mailto:[log in to unmask]>> wrote:
>     >> Martynas,
>     >>
>     >> I agree that the requirement to accommodate legacy MARC is a
>     hindrance to
>     >> the development of a more forward-looking RDF vocabulary. I
>     think that your
>     >> suggest of using SPARQL CONSTRUCT queries is not unlike the
>     concepts of
>     >> selected views or application profiles -- where you work with
>     different
>     >> subsets of a fuller data store, based on need.
>     >>
>     >> I wonder, however, how an RDF model designed "from scratch"
>     would interact
>     >> with a model designed to replicate MARC. I know that people
>     find this to be
>     >> way too far out there, but I honestly don't see how we'll get
>     to "real" RDF
>     >> if we hang on not only to MARC but to the cataloging rules we
>     have today
>     >> (including RDA). We'd have to start creating natively RDF data,
>     and until we
>     >> understand what that means without burdening ourselves with pre-RDF
>     >> cataloging concepts, it's hard to know what that means.
>     >>
>     >> All that to say that I would love to see a test implementation
>     of your idea!
>     >>
>     >> kc
>     >>
>     >>
>     >> On 1/30/15 9:03 AM, Martynas Jusevičius wrote:
>     >>
>     >> Hey,
>     >>
>     >> after following discussions and developments in the BIBFRAME
>     space, it
>     >> seems to me that it tries to be too many things for too many
>     people.
>     >>
>     >> I think many of the problems stem from the fact that (to my
>     >> understanding) BIBFRAME is supposed to accommodate legacy MARC data
>     >> and be the next-generation solution for bibliographic Linked Data.
>     >> Attempting to address both cases, it fails to address either of
>     them
>     >> well.
>     >>
>     >> In my opinion, a possible solution could be to have 2 tiers of RDF
>     >> vocabularies:
>     >> - a lower-level one that precisely captures the semantics of MARC
>     >> - a higher-level one that is designed from scratch for
>     bibliographic Linked
>     >> Data
>     >>
>     >> The conversion between the two (or at least from the lower to the
>     >> higher level) could be expressed simply as SPARQL CONSTRUCT
>     queries.
>     >>
>     >> Any thoughts?
>     >>
>     >>
>     >> Martynas
>     >>
>     >>
>     >> --
>     >> Karen Coyle
>     >> [log in to unmask] <mailto:[log in to unmask]> http://kcoyle.net
>     >> m: +1-510-435-8234 <tel:%2B1-510-435-8234>
>     >> skype: kcoylenet/+1-510-984-3600 <tel:%2B1-510-984-3600>
>
>

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
m: +1-510-435-8234
skype: kcoylenet/+1-510-984-3600