Yep, Adam, that's basically it.  It would probably be better to be a subPropertyOf bf:role or the equivalent (I think the vocab has bf:associatedAgent, but the idea is the same), but what you mocked up represents the pattern one would expect to see.

I think the biggest challenge is communicating such possibility much more widely, especially the crucial part of publishing the created property.

Warmly,
Kevin


> -----Original Message-----
> From: Bibliographic Framework Transition Initiative Forum
> [mailto:[log in to unmask]] On Behalf Of [log in to unmask]
> Sent: Wednesday, August 21, 2013 11:23 AM
> To: [log in to unmask]
> Subject: Re: [BIBFRAME] Authority - Treatment of role data
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Kevin--
>
> Could this not be something as simple as:
>
> http://my.published/ontology#sculptureCommentator
>       a http://id.loc.gov/vocabulary/relators/role ;
>       skos:prefLabel "Commentator of sculpted art work.";
>       etc.
>
> which I would then publish as part of the resource at
> http://my.published/ontology?
>
> - ---
> A. Soroka
> The University of Virginia Library
>
> [1] http://metadataregistry.org/schema/show/id/4.html
>
> On Aug 21, 2013, at 9: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.  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
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
> Comment: GPGTools - http://gpgtools.org
>
> iQEcBAEBAgAGBQJSFNtpAAoJEATpPYSyaoIkaOIH/02mX2ioEwNekbvjW9OLFhDx
> YCdv79nHUdCw/Ilg1jb71Hfy9gkdWlSiZSpOYOkllKG3vakbSfOLfAfA1BdlOBso
> X2UjHH1wmOe4xoqi2vUYt7nEXJ5fMUbZh4PYBG5Dd/5zyNCKzqQTXNqw2zU5Q5YA
> LA2EOAt8OhJyQTG0BaK/6Pb9Jh/ZPV5gw2v6jh08On8CFSK/zdtLNiM9EOV8QuHF
> Q/f2T1AMqsZ5l2pHtsTUIw6Q66S7WrgP+GWoUebfku6adax1BMvz3f2zZcyCywCF
> l2ooPE/idem5NX6kUKI4H8m4k1fjbG9JgiyGuZROPQMK9t3tCB5TlUC70ubhv3g=
> =Cq+6
> -----END PGP SIGNATURE-----