Print

Print


A "blank node" version of the example in Turtle would look like this:

work1  a  bf:Work;
            bf:accompanies  <work2 URI>.

work1 a bf:Work;
         bf:accompanies  [
                   a  bf:Related;
                   bf:relationship  "augmented by catalogue";
                   bf:identifier  <work2 URI>
         ] .


and

work1  a  bf:Work;
            bf:contributor  <URI for illustrator's name>.

work1 a bf:Work;
            bf:contributor  [
                a  bf:Related;
                bf:relationshipID  id.loc.gov/vocabulary/relators/ill;
                bf:identifier  <URI for illustrator's name>
            ].



Maybe it is helpful to discuss alternatives, because relations are
intrinsic in the predicate of subject/predicate/object RDF statements.

Imagine not a "bf" but a vocabulary "xbib" just for demonstration, so there
is no mix up between the Bibframe model and my suggestion. The task is to
relate an illustrator to a work, and testify this assertion by a library
cataloger. My proposal for such a work/illustrator relation would look like
this (in Turtle):

@prefix oa: <http://www.w3.org/ns/openannotation/core/> .
@prefix dc: <http://purl.org/dc/elements/1.1/> .
@prefix lcrel: <http://id.loc.goc/vocabulary/relators/> .
@prefix lobid: <http://lobid.org/organisation/> .
@prefix xbib: <http://xbib.org/vocab/example/> .

<http://id.loc.goc/vocabulary/relators/ill> rdfs:label "illustrated by"@en .

xbib:work1 a xbib:Work;
    lcrel:ill [
        a xbib:Illustrator;
        xbib:identifier <URI for illustrator's name>
    ] ;
  xbib:annotation [
a oa:Annotation;
        oa:hasBody xbib:work1;
        oa:hasTarget lcrel:ill;
oa:annotated "2014-01-25T16:35:00Z"^^<
http://www.w3.org/2001/XMLSchema#dateTime> ;
oa:annotator lobid:DE-605#joerg;
        oa:motivatedBy oa:identifying
  ] .

Jörg



On Sat, Jan 25, 2014 at 2:06 AM, Karen Coyle <[log in to unmask]> wrote:

>  The following is from a discussion paper [1] being presented at the MARC
> Advisory Committee at ALA. It has information about BIBFRAME treatment of
> relators (MARC relators [2] and RDA/FRBR entity relationships [3]) that I
> have not yet seen on the BIBFRAME site, so I thought it might be of
> interest:
>
>  5. BIBFRAME DISCUSSION
>
> In BIBFRAME these relationships are handled as follows.  The illustrations
> shown below use the RDF turtle notation. (See Introduction to Turtle used
> in MAC Papers <http://loc.gov/marc/mac/turtle4mac.html>.)
>
> In the BIBFRAME vocabulary the relationships between cataloging resources
> and between cataloging resources and names (commonly called roles or
> relators) such as those in Appendices J and I respectively are accommodated
> by sets of properties with the "escape" to designate any relationship not
> specifically provided.  This provides flexibility and encourages efficiency
> in expressing the relationships via URIs for the descriptions of the
> related resources where possible.
>
> For the cataloging resource relationships the set goes from the most
> general, relatedResource, to the general (which are essentially the high
> level relationship categories in the RDA Appendix J (e.g., equivalent,
> accompanies, precedes, etc.) to a number of specific relationships (series,
> translation, dataSource, supplement, etc.).  The latter includes the
> specific supersedes and precedes sub relationships used by the ISSN
> system.  Not all of the 300+ and their reciprocals are expressed as
> properties.  All of the included properties efficiently link directly to
> the URI of the description of the related resource.  If a more specific
> relationship is needed, then the relationship can be expressed in URI or
> literal form, and the link to the description of the related resource can
> be specified via the Related class.
>
> work1  a  bf:Work;
>             bf:accompanies  <work2 URI>.
>
> work1 a bf:Work
>             bf:accompanies   relationship1.
> relationship1  a  bf:Related;
>             bf:relationship  "augmented by catalogue";
>             bf:identifier  <work2 URI>.
>
> The relationships between cataloging resources and names as RDA list in
> Appendix J and the one aligned with it in MARC that also provides codes are
> similarly expressed as properties with a very general property relatedAgent
> and three general properties, agent, creator, and contributor, with
> additional relationships expressed in literal or URI form as above.
>
> work1  a  bf:Work;
>             bf:contributor  <URI for illustrator's name>.
>
> work1 a bf:Work
>             bf:contributor   relationship1.
> relationship1  a  bf:Related;
>             bf:relationshipID  id.loc.gov/vocabulary/relators/ill;
>             bf:identifier  <URI for illustrator's name>.
>
> I'm assuming that the "relationship1" in these examples is a blank node,
> although it isn't indicated as such. I'm not clear on how one knows the
> nature of the value of bf:identifier, particularly when the relationship is
> a literal string. Perhaps I'm overlooking something?
>
> kc
>
> [1] http://loc.gov/marc/mac/2014/2014-dp04.html
> [2] http://loc.gov/marc/relators/
> and
> http://id.loc.gov/vocabulary/relators.html
> [3] Not having access to the RDA toolkit, I guess the best other source
> for these is the registry recently announced: http://www.rdaregistry.info/
>
> --
> Karen [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
>
>