Enumerated types for titleInfo and relatedItem

[melanieWacker]

The LC group considered the type attributes for these elements important and meaningful. Therefore, distinct properties have been created to express them. Examples from Development of a MODS RDF Ontology: Discussion Points Ray Denenberg, Library of Congress, November 4, 2013

becomes RDF property titleUniform. becomes RDF property relatedHost. a) Do we need to carry over all the type attributes? Use cases? b) Do we agree that defining distinct properties is the best way to do this?

[infomnivore]

So, the key reference points for this conversation are: http://www.loc.gov/standards/mods/modsrdf/v1/#relatedItem and http://www.loc.gov/standards/mods/mods-outline-3-5.html#relatedItem, and http://www.loc.gov/standards/mods/mods-outline-3-5.html#titleInfo and http://www.loc.gov/standards/mods/modsrdf/v1/#title, respectively.

The related item types (enumerated: preceding, succeeding, original, host, constituent, series, otherVersion, otherFormat, isReferencedBy, references, reviewOf) have, at this point, all been translated into sub-properties of the relatedItem property, whereas those for titleInfo (enumerated: abbreviated, translated, alternative, uniform) have, with the important exception of titleUniform, not. Additionally, MODS 3.5 introduces an "otherType" for titleInfo, though, interestingly, the example given is "transliterated" (http://www.loc.gov/standards/mods/changes-3-5.html), which strikes me as a natural addition to the core enumerated types rather than an invitation to blow open the door to whatever type one wants to assert.

Looking at the way certain FRBR concepts have been elaborated into RDF (see http://vocab.org/frbr/core.html and http://vocab.org/frbr/extended.html), it seems conceivable that one might want to instantiate the titleInfo types (other than titleUniform) as properties (e.g., isAbbreviationOf /isAbbreviatedAs)--although (to my mind) they make more sense as general properties rather than sub-properties of title.

The challenge here, though, would be that in converting a MODS record into MODS-RDF the full or untranslated or fill-in-the-blank form of the title would need to be supplied in order to construct a triple. On the flip side, absent that information the titleInfo would be of questionable value as linked data. Plug any acronym into http://www.acronymfinder.com/ and you'll see what I mean. Generally, if a title is of one of these types (excepting a transliteration or, to a lesser degree, translation) and the title is not given in a "complete" or uniform type, it would be hard to determine what title or titleUniform it should have.

On the flip side, schema.org takes a minimalist approach (see http://schema.org/Thing), basically offering "name" in place of title and "alternateName" as a means to provide additional names. This actually comes closer to what the current MODS RDF looks like: name takes the place of titlePrincipal and all alternateNames (excepting the titleUniform) would simply be titles.

Personally, I think this current situation is the right-size solution for MODS RDF.

[raydAtLC]

From: Rob Hilliker [ mailto:notifications@github.com mailto:notifications@github.com]

The related item types (enumerated: preceding, succeeding, original, host,

constituent, series, otherVersion, otherFormat, isReferencedBy, references,

reviewOf) have, at this point, all been translated into sub-properties of the

relatedItem property, whereas those for titleInfo (enumerated: abbreviated,

translated, alternative, uniform) have, with the important exception of

titleUniform, not.

Well actually the omission of the type attribute in a title is functionally an enumerated type, 'primary', so you could say that both 'primary' and 'uniform' have been made into properties. The others, "translated", "alternative", and "abbreviated" actually translate to MADS RDF properties, and that’s why they don't translate to MODS RDF properties. That reason does not apply for our work, and so these too could translate directly to MODS RDF properties.

   Additionally, MODS 3.5 introduces an "otherType" for

titleInfo, though, interestingly, the example given is "transliterated"

( http://www.loc.gov/standards/mods/changes-3-5.html http://www.loc.gov/standards/mods/changes-3-5.html), which strikes me

as a natural addition to the core enumerated types

The MODS Editorial Committee decided that it would not be a good idea to add "transliterated" to the type list because any of the other types could be transliterated. (Of course you could say the same thing about "translated", but it was too late to do anything about that.)

Looking at the way certain FRBR concepts have been elaborated into RDF

(see http://vocab.org/frbr/core.html http://vocab.org/frbr/core.html and

http://vocab.org/frbr/extended.html http://vocab.org/frbr/extended.html), it seems conceivable that one might

want to instantiate the titleInfo types (other than titleUniform) as properties

(e.g., isAbbreviationOf /isAbbreviatedAs)--although (to my mind) they make

more sense as general properties rather than sub-properties of title.

I have no preference here.

The challenge here, though, would be that in converting a MODS record into

MODS-RDF the full or untranslated or fill-in-the-blank form of the title would

need to be supplied in order to construct a triple.

Not following you here.

On the flip side, absent that

information the titleInfo would be of questionable value as linked data. Plug

any acronym into http://www.acronymfinder.com/ http://www.acronymfinder.com/ and you'll see what I

mean. Generally, if a title is of one of these types (excepting a transliteration

or, to a lesser degree, translation) and the title is not given in a "complete" or

uniform type, it would be hard to determine what title or titleUniform it

should have.

Nor here.

On the flip side, schema.org takes a minimalist approach (see

http://schema.org/Thing http://schema.org/Thing), basically offering "name" in place of title and

"alternateName" as a means to provide additional names. This actually

comes closer to what the current MODS RDF looks like: name takes the place

of titlePrincipal and all alternateNames (excepting the titleUniform) would

simply be titles.

You lost me here too. Dublin Core seems to think that "name" and "title" mean the same thing, and schema.org seems to have taken its cue from DC. But we don't want to equate these two, do we? I mean a MODS name is a name of an agent for a resource, and a MODS title is a title of the resource. By "current MODS RDF" if you mean LC MODS RDF, it certainly maintains this distinction. Sorry for my confusion, please clarify.

Ray

[infomnivore]

No need to apologize: in re-reading what I wrote I can see that it isn't clear.

The crux of what I was trying to say in that section was that if a MODS record only has one title given and it is of the type translated, abbreviated, or other then there's no (easy/reliable) way to generate a triple like "TMNT""Teenage Mutant Ninja Turtles".

As to my reference to schema.org, I was simply pointing out that their name/alternateName arrangement is parallel to titlePrincipal/title. (I will add, though, that because of the way itemscope works to establish the context for interpreting data about a given item, schema.org's use of "name" for "title" works very nicely: semantically speaking, the "title" is the "name" of the book.)

[kefo]

then there's no (easy/reliable) way to generate a triple like "TMNT""Teenage Mutant Ninja Turtles".

I still think something is getting lost here.

[infomnivore]

Okay, this is less than fresh in my mind, and at this point I'm not sure even I can follow what I was trying to say! But, here's what I can pull out of it at this point: 1) keep the relatedItem types, as is. 2) the clearer articulation of the titlePrincipal/titleUniform distinction makes sense, the other enumerated types are covered by MADS RDF, and the otherType type (with the example of "transliterated") has just been introduced in MODS 3.5 so we don't have (to my knowledge) any examples of it in active use (correct me please if I'm wrong here), which makes it hard to account for...

[melanieWacker]

Discussion on relatedItem has been moved to a separate issue: https://github.com/blunalucero/MODS-RDF/issues/19

[melanieWacker]

See discussion on working group call 7.18.2014 https://github.com/blunalucero/MODS-RDF/wiki/MODS-RDF-Working-Group-Call-7.18.14