Account for Agent specific Roles

[mixterj]

right now the Conversion stylesheet does not account for specific roles between Agents and the respective Works or Images.

We could follow the Schema.org approach and use an in-between Role class that connects the Agent and the Work/Image. This Role class would have the string label for the Role (such as 'architect' as well as a URI for the role if available).

[escowles]

The other options that's been discussed is using MARC Relators or similiar properties that define roles as properties (they are defined as subproperties of dc:contributor). The benefit of this approach is simplicity: a single triple would then link from the Work/Image to the Agent.

The advantage of the schema.org approach is that it creates an intermediate node where you could attach any kind of metadata about the role the Agent played in the Work/Image. This could be the timespan of the participation, notes clarifying the exact contribution, etc.

[mixterj]

Here is some documentation about two possible ways that invoke a indirect Role node:

BIBFRAME: http://www.loc.gov/bibframe/docs/pdf/bf-roleproposal-08-12-2015.pdf Schema.org: http://dataliberate.com/2015/04/the-role-of-role-in-schema-org/ http://schema.org/Role

[amberbilley]

I want to pick this discussion back up. I'm mapping/analyzing BIBFRAME 2.0 with the VRA ontology. Just curious why it was decided to create specific Agent "role-like" properties (printer, painter, programmer, etc) than a generic role type? BF has a role property. Any thoughts on creating a role property and scrapping the Agent "role-like" properties?

[escowles]

The thinking was that the vast majority of cases can be handled by using creator/painter/performer/etc. predicates, which is in keeping with linked data best practices.

In the more complicated cases where there are multiple roles, or you want to associate annotations, qualifications, etc., you can use the existing schema.org pattern for doing that (see the blog post Jeff referenced: http://dataliberate.com/2015/04/the-role-of-role-in-schema-org/).

[amberbilley]

Right. But having specific role properties may inhibit interoperability with other ontologies.

[escowles]

@amberbilley: I'm not sure I understand the interoperability concern. Do you have an example of data in another ontology that you think would be difficult to map?

[mixterj]

The original idea, in keeping with the VRA Core 4 XML Scheme was to create direct properties based on the recommended vocabularies for assigning Agent Roles (which are the ULAN List of Artist Roles). As Esme mentioned we did have a 'safety valve' way of modeling roles that followed the Schema.org approach. If you could pull together some examples that would be great.

[amberbilley]

I'm trying to map BIBFRAME and VRA ontologies. bf:role expects a literal, while VRA has defined roles as individual properties vra:painter, vra:programmer etc. How would you map those BF literal roles to VRA role properties?

Yes, a majority of works will be defined by broad roles like creator/painter/performer/etc -- but there might be the need to define more granular roles or multiple roles. Right now there isn't a property for sculptor the VRA ontology. What other roles might be missing or be needed in the future? Why limit the ontology to specificity?

So the safety valve would be to just use schema:Role?

[amberbilley]

Also there isn't a general "artist" property. That's something we really need for our Art Properties data if we were to use something like VRA.

[rguenther52]

I might note that the BIBFRAME paper on roles allowed for use of a URI as a property (http://www.loc.gov/bibframe/docs/pdf/bf2-roles-apr2016.pdf) so it is not always a literal. However there are changes being discussed about agent roles-- I'll keep you posted about the decisions (although I suppose Amber and Melanie will hear about it through the LD4star project).

Rebecca Squire Guenther 215 W. 75th St. Apt. 16H New York, N.Y. 10023 703-298-0157 rguenther@gmail.com http://www.meetyourdata.com

On Tue, May 17, 2016 at 11:50 AM, amberbilley notifications@github.com wrote:

Also there isn't a general "artist" property. That's something we really need for our Art Properties data if we were to use something like VRA.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/mixterj/VRA-RDF-Project/issues/3#issuecomment-219762245

[escowles]

@amberbilley I'm looking at the Bibframe role spec (http://www.loc.gov/bibframe/docs/pdf/bf2-roles-apr2016.pdf), and the first thing it says is that if you have an RDF predicate for a role, you can use it as a property. So I think you can simply use the VRA predicates directly on Bibframe resources, or you can map them to other predicates (schema.org, DC, or MARC Relators) if those work better with the other data you're working with.

[rguenther52]

Yes, as I mentioned some changes are being considered. In any case, the predicates that BIBFRAME suggests is using the URIs at http://id.loc.gov/vocabulary/relators.html (i.e. MARC relators). DC predicates are just dc:creator, dc:contributor and dc:publisher and otherwise use MARC relators for other roles.

[amberbilley]

@rguenther52 thanks for the BF paper on roles. I forgot those about those specification papers :-)

@escowles I doing more of an ontology comparison between BF and other Art related ontologies (VRA, CIDOC-CRM, schema, FRBRoo, etc). An intellectual exercise really. So I just noticed the difference in approach to roles between BF and VRA, and was curious about it. I understand that I can simply use other predicates that work better with our data.