MODS Survey #1 Results:

Raw Survey Results: https://docs.google.com/spreadsheets/d/1Hd3LtMpAsTQhiuerVLok9rxfJrKXJJ_OFb6SUAHHieQ/edit?usp=sharing

What is the scope of any "unofficial" standard from this group?

Do you care if you can regenerate semi-equivalent MODS XML from this RDF mapping?

Which mapping did you think held the most promise for the title element as a starting point? 

Are you against the minting of local URIs at all costs?

Is there anything you particularly liked about the mapping models provided?

Support for supplied, uniform, parallel, and translated titles in BPL models.

I liked that we all seemed to agree on heading towards a simple RDF statement for title and, in general, using the same namespace (DC or DCTERMS). That makes me feel like we're all thinking about this the same way, which hopefully means we'll be able to agree on a common overall mapping for MODS to RDF.

Is there anything you particularly disliked about the mapping models provided?

None of us dealt with @supplied very well (or at all). I'm not sure we're ready to give up this attribute, but we also don't know what to do with it while keeping our mapping simple.

I am uneasy with using both dcterms:title and skos:prefLabel for different values. I would think that dcterms:(or dc:)title, rdfs:label and skos:prefLabel should all be identical for an object.  

Lack of support for supplied, uniform, parallel, and translated titles in some models. Loss of specificity in most model examples.

I think our process and discussion are going well so far and we're working through issues that we need to figure out.

I'm a little wary of relying entirely on dc:title, as many of the models did -- for a simplified version, sure, I think that we will run up against the limits of that very quickly.  

Other comments / feedback / ideas on how to handle this process or about the group in general?

It might be helpful to come up with a list of acceptance criteria for both simple and complex solutions for each element, so we can make expectations clear.

I think mapping BACK to MODS is unnecessary. If you already have MODS prior to transform to RDF, Fedora allows you to save it as a bitstream. Maybe just do that if you feel you'll need MODS again.

On the second question, yes to some extent.

Difficult to answer number 3 because everyone started with such different scenarios, and because I think we should go with two versions of the mapping. For a complex mapping, I think BPL's was the most thorough and that people could scale that back if needed, so that would be a good place to start.

On the question about minting, I get the sense that it will probably be necessary for certain data. . 

It seems likely that we will need to propose strategies for metadata modeling that support both simple and complex use cases. Some institutions may have a lot of existing MODS metadata that they are unwilling to "round down" to a lower common denominator. However, some institutions simply don't need a high level of specificity when it comes to MODS subelements and attribute values.

I like the idea of dealing with a "core" set of MODS elements that will need to be expressable in RDF for data functionality purposes (indexable data for search and browse and core data required for object identification). As a group, we need to spend some time to determine those if we go that route. Beyond that, I would consider other MODS elements to be those "optional additional elements for more complex cases" and I would also like us to consider a recommendation that the full static MODS XML be kept as a NonRDFResource on any object migrated from Fedora 3 to Fedora 4. If it's possible, I think it could also be worth it for us to share our findings and recommendations with the LOC group responsible for MODS in RDF - this might help them determine a more use-able way to express MODS as RDF or at least hear about the kinds of practical problems being encountered with their current transformation.

I like the idea of providing a couple of options as guidelines. Not everyone is going to need to map to the same level of complexity, but at the same time, I think we want the output of this working group to be useful beyond the most basic level that can be expressed by Dublin Core.