Time: 9am PDT / Noon EDT
Call-In Info: 712-775-7035 (Access Code: 960009)
Moderator: Steven Anderson (Boston Public Library)
Primary Notetaker: TBA (etherpad for roll call: https://etherpad.wikimedia.org/p/RDF-MODS-20151005)
- Fedora 4 Test Code:
- Code base to try MODS title element in Fedora 4 -- hopefully will happen this week so people can take a look at how that's being represented within the next week or so.
- Overview of MODS name mapping attempts
- Anybody want to go over their mapping attempt who wasn't on the call last time?
- Basically just used Dublin Core terms for her example.
another option is to use MARC relator as URI instead of DC terms as Creator -- these are sub-properties of DC terms already, and are more precise than just Creator/Contributor
DC:Creator and DC: Contributor with a literal text string; this actually has to be a URI value, literal values are not allowed
Can literals be used with MARC relators? No, as sub-properties of DC:Creator and Contributor, they inherit the same restrictions
how do you solve this? make your own URI, create a blank node?
- Document that talks about DC terms elements -- will be added to the notes afterwards, good reference for what can and can't be used with DC properties
- Favorite mapping that anyone wants to talk about that wasn't their own mapping?
Steven: if we write a shared code base to translate from MODS XML into whatever MODS RDF ends up being, it's necessary to make some of these decisions for what it spits out. So mostly just in terms of collaborating coding efforts more than whether or not it's syntactically valid
Remark: so much variation in how people are structuring name or using it, how general is this going to be?
- There's a lot of particular use cases, people are always still welcome to do the things that they want to keep doing, nothing is binding, but this is a long process and there is something to be gained from having some kind of consensus; still, "recommendation" has to be taken with as many grains of salt as possible based on use case.
- Julie: we're turning what we're doing into an actual transformation, can we look at this more as creating a base transformation for people to go from? Can this help us streamline what we're doing so we're not having to imagine all the cases and decide what cases are relevant, start with a baseline transformation, give options if time allows for additional features that could be transformed? Part of the recommendation, place where people can start and an aid.
- Steven: definitely a place where people can start, but also want to make sure it's something that works and makes sense in and of itself
- Julie: if name has multiple parts involved, just bringing them all together as a baseline and dealing with it as a single thing seems like a useful starting point
- Steven: Definitely possible, but do we want that to be the maximum amount of specificity that we want to do or should the transformation be intelligent enough to break that out as well? Maybe it's a difference between the simple and complex as to how much it breaks out and how much it retains? If original source records have data split out, do we retain that specificity or agree as a group that it will be lost?
- There's no upper limit on specificity that people can implement in their own institutions, but what's the minimum level of specificity that we're recommending or an out-of-the-box transformation would provide? If we're looking at the out-of-the-box use case then having the entire name as a SKOS prefLabel seems like a reasonable baseline.
- Simple version could just be the simple label and complex could have a few pieces of information broken out but otherwise would be the same
- Julie: Complex could serve as an example if there's more information that people want to break out.
- Other topics to discuss: what do you do about ordering? If you have multiple authors and you're trying to keep a consistent ordering because the first author would get upset if he wasn't listed first, anybody think of approaches for that?
- Steven: BPL's attempt at a solution (last example in our mapping document), if you have two authors, would have them still linked like normal, only difference is that you would have an additional predicate that is author # order with an RDF list that would represent the URIs that make up that order, so if you have an object that cares about order, you would have the property that would create a listing of what the order is, and if you don't care about order you don't need to worry about supporting that predicate.
- Question: Do you want to add that # order suffix onto a relator term or use something more simple like DC terms Creator? Lots of different relator terms, do you always use relator author to represent order, or would it be an easier/more general use case to use DC terms Creator to represent order?
- Steven: Adds complications, because some are subproperties of contributor instead of creator, also then you have to order all the objects rather than just author if you only care about author.
- Will you want to order different names with different rules in some cases? Wouldn't you want generic name predicates rather than a specific relator that corresponds to one but not all of the names?
- Danny: we're not an IR, we don't have a lot of books and papers with multiple authors where order becomes important, but lots of items with lots of different kinds of creators, and would want some generic way to retain order of creators rather than specifically for authors
- Julie: Anything in MODS allow this same sort of ordering?
- Steven: XML by definition retains hierarchy and structure within document, so a name that comes into an XML document first is by default the first name. RDF statements are inherently unordered and can be reordered within the data store, may come back 1st in the results first time and 15th next time.
- Someone else: MODS also has ability to add usage attribute, usage=primary or something, but that is only used for primary author -- doesn't preserve anything beyond "this is number one"
- Is the worry with multiple names that there will not be enough role ability in MARC relator to differentiate people by roles, which can then be ordered? Can you identify roles by order, and then identify individuals within roles by # order?
- Steven: you can definitely support both, depends on what use cases exist and what people want to support. Will be custom property however we define it, question of whether you want to order by sub-property or order every single name in the record.
- Consensus seems to be to order all marc relator terms if order is needed. So rather than "authors" and "photographers" having different order predicates, they would all be ordered in one order predicate...
- Another topic: problem with affiliation
- BPL is fine with dropping it, but at HydraConnect sounds like Emory and University of Alberta would have uses cases where they would need that
- U of Alberta: not 100% sure (Note: Later clarified via email that they don't have a need for it)
- (Emory University reiterated their need via email since they couldn't make this call).
- Attempt in BPL's most recent mapping to solve this but solution isn't that feasible.
- No one else has any ideas how to solve this issue.
- Punted on for now until the next call.
- Simple vs. complex - simple version will be still using MARC relators to indicate the role, would resolve to a local URI that is simply a prefLabel. In complex case, would support prefLabel and then a few other broken-out properties.
- What's the difference again?
- In simple case, MARC relator that goes to a local URI and then just goes to a prefLabel; in complex case, same thing but support a few additional properties like birth/death date or affiliation if that needs to be supported in an example.
- Action Items
- BPL will attempt initial implementation, see what this looks like in Fedora, throw in MODS XML records and see what comes out of them
- Homework: start looking at the next element in MODS, individual use cases & attempts at mapping -- Type of Resource, which is theoretically less complicated.
- Take a look at the collaboration document for Name once it is up.