On 8/21/13 9:34 AM, Gordon Dunsire wrote:
[log in to unmask]" type="cite">
Karen

I think the MARC relator codes are already declared as instances of
skos:Concept, as well as rdf:Property; see the "other" example given by
Kevin. But they are not in a separate list; the same URI is declared an
instance of Concept and Property.

Hmm. It seems odd that the same URI would be used for both a property and a SKOS concept. The SKOS standard doesn't prevent this (it's very liberal), but I'm puzzling over what it means in an implementation.

A -> [some SKOS Concept/Property] -> B

A -> [some Property] -> [some SKOS Concept/Property]

For a term like "Author" it seems that it could either mean "is author of" or "has author" or "is an author".  The definition begins: " A person, family, or organization responsible for creating a work that is primarily textual in content..." Would all of these be valid/sensible?

John -> lc:author -> Big Book
BigBook -> lc:author -> John
John -> bf:role -> lc:author
lc:author -> bf:role -> John

My attempts to see what happens with content negotiation failed, so I can't see how the URI self-identifies. Boh.

[log in to unmask]" type="cite">

Btw, I don't think "other" is an RDA relationship designator. The
"Definition notes" (is that the same as a definition?) for the MARC relator
cited by Kevin are "A role that has no equivalent in the MARC list", so I
guess it is a MARC relator grab-bag for RDA relationship designators that
have no MARC relator code equivalent. Apologies if I've got this wrong.

Gordon, when we were inputting the RDA vocabularies there often was an "other" included in the RDA text. "Other", however, is pretty useless as a term unless you have a way to say what the "other" is (like on some forms where "other" is followed by a blank line that you fill in). We talked to the JSC about possible solutions to this from an application point of view, but of course there is no application so there is currently no solution. Basically, you need to capture SOMETHING that can be helpful in the future, something that lets you know what the cataloger encountered (e.g. a new physical format for which there wasn't a vocabulary term yet). Even a text note would be better than just "other".

kc

[log in to unmask]" type="cite">

For a discussion on the semantic relationship between RDA relationship
designators and MARC relator codes, see the discussion paper submitted to
JSC [1], and the related appendix 1 [2]

Any comments are most welcome!

Cheers

Gordon

[1] http://www.rda-jsc.org/docs/6JSC-CILIP-rep-3.pdf
[2] http://www.rda-jsc.org/docs/6JSC-CILIP-rep-3-Appendix-1.pdf


-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum
[mailto:[log in to unmask]] On Behalf Of Karen Coyle
Sent: 21 August 2013 23:20
To: [log in to unmask]
Subject: Re: [BIBFRAME] Authority - Treatment of role data

On 8/21/13 6:46 AM, Ford, Kevin wrote:
Dear Stephen,

The option of listing the same name in two role properties for the 
same resource is a reasonable solution to the multi-role problem....
It also keeps the role specification in the BIBFRAME Work where I 
think it belongs.
-- This, this is the objective.

It is anticipated that all the MARC Relator codes - already instantiated
as properties - will be available in BIBFRAME.

Kevin, doesn't this, in a sense, answer the question at 3.2 "A Role
resource?" That method requires an object for the role, that is, a noun, not
a property (verb). This is the same situation that we discussed in the
annotation arena -- BIBFRAME is using individual properties to relate the
body to the annotation, while Open Annotation has a general relator
(hasBody) and then allows the body to be typed using any defined "thing".
That's a "verb vs. noun" situation.

With the MARC relators as properties, they cannot be used as the role "noun"
as shown in 3.2. A new list would need to be developed, probably defining
the terms as SKOS concepts, to accommodate this option. In theory, with the
role as a noun, one could make use of terms from sources like DBpedia, like
http://dbpedia.org/page/Animator, which is defined as a "thing" rather than
a property, but I suspect that many in the library world would frown on
using terms from there.

It seems to me that the decision to be made isn't so much about the
structure of the authority but the anticipated uses, including vocabulary
maintenance (as you mention) and linking to other communities that create
bibliographic data. This is less of a question for subjects since there is
only one relationship there, at least as we have currently defined it. I can
imagine having primary and secondary subjects, or some other refinement of
"has subject" but we don't have that now -- however, if we did want to
refine subject, then we'd have the same question to answer.

kc






  The MARC Relators list and RDA relationship designators (mostly Appendix
I) were reconciled earlier this year (it was not announced on this list,
which seems like an oversight presently, but you can find the original
announcement here [1]).  RDA included an "other" [2].  We are exploring
integrating those properties with the overall BIBFRAME vocabulary, which
will infuse the BIBFRAME vocabulary with over 250 resource-to-agent
relationships.
If one of more than the 250 relationship properties is not appropriate,
there is a way to essentially generate a custom relationship (i.e. property)
and use it instead. Creating one's own relationship/property will require
slightly more infrastructure than simply inputting a relationship into a
free-text field, but will ultimately create data that is more machine
actionable.  In part this will require an education effort (that is, a "how
to") and partly it will require thinking about how to integrate custom
property creation (and exposure) into system design.
For example, you find you absolutely need a property for "Commentator of
sculpted art work."  There is a way to mint such a property and use it in
your data, but what will be needed (beyond an educational effort that
describes this more fully) is a system that 1) can accommodate this need and
2) actually publish the URI for your custom property in order to help others
to understand it.
Warmly,
Kevin


[1] 
http://listserv.loc.gov/cgi-bin/wa?A2=ind1305&L=marc&T=0&X=54463610E73
528A6E1&P=1046 [2] http://id.loc.gov/vocabulary/relators/oth



-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum 
[mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Thursday, August 15, 2013 6:15 PM
To: [log in to unmask]
Subject: Re: [BIBFRAME] Authority - Treatment of role data

The option of listing the same name in two role properties for the 
same resource is a reasonable solution to the multi-role problem, 
especially if there's a way to assign a name to a less or 
un-specified or an invented role property. It also keeps the role 
specification in the BIBFRAME Work where I think it belongs.

I still worry that it might lock down the vocabulary for describing 
role with BIBFRAME, assuming "author" and "illustrator" in the 
example are BIBFRAME properties. Having native BIBFRAME define a more 
limited set of generic relationship categories and letting a type 
attribute with a declared source vocabulary determine what the role 
terms/codes are used in a given implementation seems more flexible.

Stephen

On Thu, Aug 15, 2013 at 4:28 PM, Ford, Kevin <[log in to unmask]> wrote:
Dear Stephen,

Thanks for the comments.  A few answers and comments of my own follow:

Will a single person playing
multiple roles be entered as multiple property statements for the
same
resource, or will there be a way to specify multiple roles in the 
context of a single property statement?
-- The document does not include an example of this, but here is one:

<!--  BIBFRAME Work -->
<Book id = "http://bibframe/work/the-garden-of-abdul-gasazi">
     <title>The garden of Abdul Gasazi</title>
     <author resource = "http://bibframe/auth/person/chris-van-allsburg"
/>
     <illustrator resource = " http://bibframe/auth/person/chris-van-
allsburg" /> </Book>

<!--  BIBFRAME Authority -->
<Person id="http://bibframe/auth/person/chris-van-allsburg ">
         <authorizedAccessPoint>Van Allsburg, 
Chris</authorizedAccessPoint>
         <hasAuthority
resource="http://id.loc.gov/authorities/names/n79071437" /> </Person>

Two (defined) role properties on the Work both point to a single 
Person Authority.


Will BIBFRAME have an option
for unspecified or "other" role, given that the role terms appear to 
be part of BIBFRAME's controlled vocabulary in Example 2?
-- Yes.


The addition of Role as a BIBFRAME Authority resource mediating 
between a Work and a Person in 3.2 would lead to requiring multiple 
BIBFRAME Authorities for the same entity playing different roles.
-- There would be a separate Role resource for every role, but there 
would be only one BIBFRAME Authority per entity.  If this isn't 
clear, I can work up a more detailed example.


Section 3.4
-- About section 3.4: For starters, I'll probably rename it Anomalous 
Data in a revision.  Good word, wish I had thought of it.  To be 
clear, I don't like what's being proposed, but in the interest of a 
simpler, future solution I worry about adopting a overly complicated 
approach (which, I believe, is what the Role proposal is) in order to 
accommodate anomalous data, which is, on the whole, a small 
percentage of existing data and, if we can envision better cataloging 
interfaces in the future, I would hope a non-existent issue.  I'm 
also not crazy about two different approaches; when it comes to 
exchange and comprehension, we'll all benefit from a single solution 
(even if it isn't perfect in 100% of cases).


Rather than either of these, would it be possible instead to limit 
BIBFRAME Work properties to Creator and Contributor (roughly 
reflecting the distinction in Simplified Dublin Core and MARC's
1XX/7XX) and then allow repeatable Type attributes or a Type
attribute
with multiple values for those the Creator and Contributor 
properties to specify role more precisely for a given entity's 
relationship to a
resource?
-- In many ways what you are proposing here is the Role resource 
avenue, especially when you start talking about typeTerm, typeCode, 
and typeURI attributes/properties.  But, before we continue this 
conversation, I have two quick questions for you:

1) Does my example above - demonstrating how to relate one Person 
Authority with multiple roles to a Work - impact your questions?
2) What is it *you* want to do?  I ask because I started to wonder 
what benefit you saw in limiting Work properties to Creator and 
Contributor followed by a whole typing system.


Yours,
Kevin



-----Original Message-----
From: Bibliographic Framework Transition Initiative Forum 
[mailto:[log in to unmask]] On Behalf Of Stephen Hearn
Sent: Thursday, August 15, 2013 2:26 PM
To: [log in to unmask]
Subject: [BIBFRAME] Authority - Treatment of role data

The modeling of role in 2.2 has problems.  Will a single person 
playing multiple roles be entered as multiple property statements 
for the same resource, or will there be a way to specify multiple 
roles
in
the context of a single property statement? Will BIBFRAME have an 
option for unspecified or "other" role, given that the role terms 
appear to be part of BIBFRAME's controlled vocabulary in Example 2?

The addition of Role as a BIBFRAME Authority resource mediating 
between a Work and a Person in 3.2 would lead to requiring multiple 
BIBFRAME Authorities for the same entity playing different roles.
That
runs counter to the plan of having one BIBFRAME Authority per
entity.
Section 3.4 acknowledges this, but argues that multi-role cases (or
at
least those resulting from anomalous data) will be a "very, very
small
percentage of the whole"--but inevitably it will tend to be those 
named entities which are most prolific which will turn out to have
the
most roles (and the most anomalous roles in existing data), so
dealing
with these cases more efficiently will still be a concern.

Rather than either of these, would it be possible instead to limit 
BIBFRAME Work properties to Creator and Contributor (roughly 
reflecting the distinction in Simplified Dublin Core and MARC's
1XX/7XX) and then allow repeatable Type attributes or a Type
attribute
with multiple values for those the Creator and Contributor 
properties to specify role more precisely for a given entity's 
relationship to a resource? The Type attribute would not be 
required, so if an agent's role has no controlled value, the agent 
could still be named in relation to the Work in more general terms 
as a Creator or Contributor. BIBFRAME Instance records might need to 
add another general role term or two, but would leave more specific 
role terms to
a Type attribute.
The "bad data" case could be managed by defining a separate 
"typeUnrecognized" attribute which could contain any text. To ensure 
better control of "good data", the Creator/Contributor Type
attributes
might be expanded into typeTerm, typeCode, and typeURI, each with 
declared schema-level or implementation-level parameters.

Adding a new work in which someone named in an existing BIBFRAME 
Authority has a new role should not require adding a new BIBFRAME 
Authority. Making role part of the BIBFRAME Authority will place a 
burden on it which a lightweight abstraction layer shouldn't have to 
carry.

Stephen

On Wed, Aug 14, 2013 at 4:33 PM, Ford, Kevin <[log in to unmask]> wrote:
Dear All,

We wanted to share two documents with you all.  One is new, the 
other is an updated version.

The BIBFRAME Use Cases and Requirements document "...specifies use 
cases, requirements, and objectives for BIBFRAME. It suggests how 
BIBFRAME supports a variety of traditional and forward looking uses 
cases, describes the communications environment for the use cases in 
BIBFRAME, and describes the model communication format and 
acceptable serializations. For each use cases, supporting 
requirements and
design
objectives are defined."

The Use Case and Requirements document is not inclusive.  We fully 
anticipate adding to it.  In fact, we hope and expect the document 
will elicit additional use cases from the community.  But, besides
new
use cases, we encourage feedback about the ones detailed in the 
document.  It is accessible at:

http://bibframe.org/documentation/bibframe-usecases/

The second document is a significant revision of the /On BIBFRAME 
Authority/ discussion paper.  The current version reflects changes, 
additions, and deletions stemming largely from your feedback - thank 
you.  Although it has been slightly re-engineered toward acceptance
of
the "lightweight abstraction layer," the major issues - outlined in 
the previous version or raised from listserv comment - are still 
represented.  As before, we look forward to the discussion.  The 
revised version is available at:

http://bibframe.org/documentation/bibframe-authority/

When starting a new topical thread about the papers, please start a 
create new email with a descriptive subject, such as "use cases --
web
triggers," "use cases -- authority reconciliation," or "authority -- 
direct approach."

Yours,
Kevin

--
Kevin Ford
Network Development and MARC Standards Office Library of Congress 
Washington, DC




--
Stephen Hearn, Metadata Strategist
Technical Services, University Libraries University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428


--
Stephen Hearn, Metadata Strategist
Technical Services, University Libraries University of Minnesota
160 Wilson Library
309 19th Avenue South
Minneapolis, MN 55455
Ph: 612-625-2328
Fx: 612-625-3428
--
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

-- 
Karen Coyle
[log in to unmask] http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet