Print

Print


Hey again,

I want to illustrate what I mean with the 2 tiers and the mapping
between them with an example.

I used one of the data samples from Jörg's link (about "Aristotle on
mind and the senses") and created a SPARQL query:

PREFIX field: <rdfmab:field#>
PREFIX dct: <http://purl.org/dc/terms/>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX bf: <http://bibframe.org/vocab/>
PREFIX foaf: <http://xmlns.com/foaf/0.1/>
PREFIX skos: <http://www.w3.org/2004/02/skos/core#>

CONSTRUCT
{
  ?work a bf:Work ;
    dct:created ?createdDate ;
    dct:modified ?modifiedDate ;
    dct:language ?language ;
    bf:title ?title ;
    bf:creator [ a foaf:Person ; foaf:name ?creatorName ] ;
    dct:subject [ a skos:Concept ; skos:prefLabel ?categoryLabel ] .
}
{
  ?work field:902__p|field:902__s ?categoryLabel .
  ?work field:002a_a ?createdString .
  BIND (STRDT(?createdString, xsd:date) AS ?createdDate)
  ?work field:003__a ?modifiedString .
  BIND (STRDT(?modifiedString, xsd:date) AS ?modifiedDate)
  ?work field:036a_a ?language .
  ?work field:101__a ?creatorName .
  ?work field:331__a ?title .
}

You can try running it here:
http://graphity.dydra.com/graphity/marc-test/sparql#marcrdf2bibframe

This query is a declarative, platform-independent mapping between 2
"tiers" (levels of abstraction) of bibliographic data:
1. syntactic MARC-RDF, in this case specified by Jörg
2. conceptual real-world representation, as a mix of BIBFRAME, SKOS,
Dublin Core and other relevant vocabularies

By no means I claim that this is an complete or semantically correct
example, but I hope it gives a better idea of my suggestion.
Feel free to expand and modify it.

Martynas
graphityhq.com

On Sat, Jan 31, 2015 at 5:16 PM, [log in to unmask]
<[log in to unmask]> wrote:
> Because MARC is a key/value stream with a string-based encoding semantics,
> this does not justify a "direct mapping" to RDF. This is problematic.
>
> From an implementor's view, a correct migration to RDF means to parse MARC
> records, map selected MARC-encoded values to functions/objects, evaluate
> contextual information and more semantic information from other sources
> (catalog codes, authority files), and let the mapping functions create RDF
> graphs with the transformed information in it, adding datatype information,
> links etc.
>
> I invented something similar to your bfm proposal internally back in 2010.
>
> https://wiki1.hbz-nrw.de/display/SEM/RDF-ISO2709+-+eine+RDF-Serialisierung+fuer+ISO+2709-basierte+bibliografische+Formate+%28MARC%2C+MAB%29
>
> When asked for documenting the format, I hesitated and tried to describe it
> as an intermediate serialization format and called it "RDF/ISO2709". But the
> very bad side effect was that librarians who were not familiar with RDF and
> the semantics of RDF thought RDF was just a wrapper mechanism like XML, they
> called RDF a "format" and did not take it seriously as a modern graph model
> for the bibliographic data of future catalogs.
>
> Karen picked up the idea 2011 in
>
> http://lists.w3.org/Archives/Public/public-lld/2011Apr/0137.html
>
> So, from my personal experience, I do not recommend to propose a
> MARC-centered "serialization only" Bibframe dialect. It will not improve
> Bibframe or ease the migration, it will just add a truncated RDF without
> links, without URIs, with another migration path.
>
> If Bibframe can be seen as the "one-size-fits-all" RDF model for MARC, is
> another question. For much of the data I have, Bibframe is not my first
> choice.
>
> Jörg
>
>
> On Sat, Jan 31, 2015 at 1:14 PM, Martynas Jusevičius <[log in to unmask]>
> wrote:
>>
>> Jeff,
>>
>> there is one reality, but it can be described in many different ways.
>> And yes, there should be a separate RDF vocabulary for each level.
>>
>> Here's a completely fictional example to illustrate what I mean:
>>
>> 1. MARC-syntax level
>>
>> _:record a bfm:Record ;
>>   bfm:recordType "Book" ;
>>   bfm:isbn "123456789" ;
>>   bfm:title "The Greatest Works" ;
>>   bfm:author1givenName "John" ;
>>   bfm:author1familyName "Johnson" ;
>>   bfm:author2givenName "Tom" ;
>>   bfm:author2familyName "Thompson" .
>>
>> 2. Linked Data level
>>
>> <books/123456789#this> a bld:Work, bldtypes:Book ;
>>   dct:title "The Greatest Works" ;
>>   bld:isbn "123456789" ;
>>   bld:authors (<persons/john-johnson#this> <persons/tom-thompson#this>) .
>>
>> <persons/john-johnson#this> a foaf:Person, bld:Author ;
>>   foaf:givenName "John" ;
>>   foaf:familyName "Johnson".
>>
>> <persons/tom-thompson#this> a foaf:Person, bld:Author ;
>>   foaf:givenName "Tom" ;
>>   foaf:familyName "Thompson".
>>
>>
>> Both examples contain the same information, but it is encoded very
>> differently. Clearly the Linked Data style is preferred, and the MARC
>> vocabulary could in theory go away when there are no more legacy MARC
>> systems to support.
>>
>> I haven't seen any actual MARC data, but if someone has a simple
>> example, we could work on that.
>>
>> Martynas
>>
>>
>> On Sat, Jan 31, 2015 at 4:21 AM, Jeff Young <[log in to unmask]>
>> wrote:
>> > Tim,
>> >
>> > The semantics behind MARC is based on reality. MARC cares (may) too much
>> > about which names and codes should be used in various structural
>> > positions,
>> > but there are real things lurking behind those.
>> >
>> > Jeff
>> >
>> >
>> >
>> > On Jan 30, 2015, at 9:58 PM, Tim Thompson <[log in to unmask]> wrote:
>> >
>> > Karen,
>> >
>> > Aren't the semantics behind MARC just the semantics of card catalogs and
>> > ISBD, 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, sadly,
>> > they
>> > left out the punctuation ;-)
>> >
>> > Tim
>> >
>> > --
>> > 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]>
>> > 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]>
>> >> > 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
>> >> >
>> >> >> On Fri, Jan 30, 2015 at 10:15 PM, Karen Coyle <[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] http://kcoyle.net
>> >> >> m: +1-510-435-8234
>> >> >> skype: kcoylenet/+1-510-984-3600
>> >
>> >
>
>