Type attributes for abstract, accessCondition, tableOfContents, and targetAudience

[melanieWacker]

The type attributes for these elements have not been carried over from MODS XML to LC MODS RDF. Are there use cases that indicate that this decision should be reconsidered?

[infomnivore]

Re: "abstract"

See http://www.loc.gov/standards/mods/mods-outline-3-5.html#abstract for the MODS outline notes on the abstract field.

The example types offered there are:

review, scope and content

My sense is that a review of a work is a not an abstract per se, so that example is moot. I'm not certain how "scope and content" would differ from a generic abstract, so that may be moot as well.

Sampling a few of the MODS implementations, I see none that use a type attribute for abstract.

From a meta-level, I should add that abstract is one of the most valuable MODS fields, in my experience, for discovery purposes, but I wonder about its value in a LOD environment: thoughts?

[melanieWacker]

My feeling is that MODS users who already have abstracts in their legacy data will need a place to put this information rather than lose it. However, I agree that so far I have not seen a single implementation that uses the type attribute. I like the idea suggested by Jeff, to develop a best practice document along with the MODS RDF that discusses the value of specific elements (such as notes or abstracts) in a linked data environment. I can also envision linking out to an external abstract, such as one provided by a publisher.

[infomnivore]

Re: "accessCondition", see http://www.loc.gov/standards/mods/mods-outline-3-5.html#accessCondition

For an example of these properties being used in practice see http://library.princeton.edu/departments/tsd/metadoc/mods/accessconditions.html

Princeton's examples suggest that this metadata is mapped to specific MARC fields: perhaps we should consider that there may be a path here for legacy metadata that we don't want to close off?

accessConditions is extensible, but the schemas commonly used to extend it (e.g., copyrightMD) are often more narrowly defined and have not be translated into RDF schemas, with the major exception of PREMIS. Looking at PREMIS RDF (http://id.loc.gov/ontologies/premis.html) is instructive, however, as the concepts that Princeton seeks to convey in their use of the types is covered by the classes and properties in PREMIS RDF.

Perhaps this calls for an entry in the best practices document! :+1:

[infomnivore]

Re: table of contents, see http://www.loc.gov/standards/mods/mods-outline-3-5.html#tableOfContents.

It gives a couple of (redundant) examples, but these are not enumerated types. I see no reason to carry over types for "tables of contents"--on the other hand, it would be nice to open this one up to URIs in addition to strings!

[infomnivore]

Re: target audience, see http://www.loc.gov/standards/mods/mods-outline-3-5.html#targetAudience and http://www.loc.gov/standards/valuelist/marctarget.html.

I think the important piece here is that there is already in MARC21 a defined vocabulary for target audience: we should reassert that clearly by creating a set of URIs at http://id.loc.gov/ that could be swapped in for the string values.

Alternatively, we could

[melanieWacker]

Re: targetAudience, I see that the MARC21 vocabulary was also carried over as example values into the MODS RDF Namespace document: http://www.loc.gov/standards/mods/modsrdf/v1/#targetAudience It would be nice to have those available on http://id.loc.gov/. Any plans for that?

[melanieWacker]

Re: tableOfContents and abstract: Should we propose that all attributes, including type, will not be carried over into MODS/RDF? Opinions?

[raydAtLC]

For tableOfContents: I think we all agree that we should not be creating a blank node (or structure) just to represent an arbitrary type. That doesn’t necessarily mean that we don’t want to represent types. But I don’t know what types of table of contents there are. In the example, only “partial content” is given. Perhaps there are others, but I think we should decide case by case whether a separate property is warranted. So, there would be a property ‘tableOfContents’ and then, if warranted, another property ‘tableOfContentsPartial’, and so on, subproperties of ‘tableOfContents’. And of course, the other attributes: altRepGroup, altFormat, etc. certainly don’t need to be carried over (with the exception of xml:lang).

The same would apply to abstract. There would be a property ‘abstract’ and then zero or more additional properties representing specific types of abstracts: ‘scope’, ‘contentAdvice’, ‘review’, all could be subproperties of ‘abstract’.

Or did I misunderstand the question?

Ray

From: melanieWacker [mailto:notifications@github.com] Sent: Thursday, May 15, 2014 4:54 PM To: blunalucero/MODS-RDF Subject: Re: [MODS-RDF] Type attributes for abstract, accessCondition, tableOfContents, and targetAudience (#8)

Re: tableOfContents and abstract: Should we propose that all attributes, including type, will not be carried over into MODS/RDF? Opinions?

— Reply to this email directly or view it on GitHub https://github.com/blunalucero/MODS-RDF/issues/8#issuecomment-43263393 . https://github.com/notifications/beacon/4854536__eyJzY29wZSI6Ik5ld3NpZXM6QmVhY29uIiwiZXhwaXJlcyI6MTcxNTgwNjQzNiwiZGF0YSI6eyJpZCI6MjMxNTkxOTR9fQ==--076cda34e2327dddb19a6cba950b5cd9c2e675c9.gif

[melanieWacker]

For tableOfContents: In MARC 21 there are two "types" represented by indicators: Incomplete contents and Partial contents. See http://www.loc.gov/marc/bibliographic/bd505.html That's probably where the example was taken from. I can't think of any other types, but I can see a possible need to express that a tableOfContents is incomplete.

Abstract: The examples given are also taken from MARC indicators: http://www.loc.gov/marc/bibliographic/bd520.html. However, most of these are fairly close in meaning (to me at least) and, as was pointed out in an earlier posting, a review seems to be quite a different animal from an abstract. So not sure that's enough reason to create a subproperty if there isn't a controlled list in MODS itself?

accessCondition: It seems we would lose too much granularity if we did not express at a minimum the two suggested types (restriction on access and use and reproduction)

[melanieWacker]

Recommendations from 5.20.14 conference call: abstract: Type values should not be carried over into MODS/RDF. Not an enumerated list. tableOfContents: Type values not an enumerated list, but the ability to indicate if the contents is complete or incomplete is important. Create subproperties for contents, incomplete contents, partial contents accessConditions: Retain suggested type values “restrictions on access” and “use and reproduction” targetAudience: Not discussed at this call.

[rguenther52]

Target audience is already at id.loc.gov, although it was never announced: http://id.loc.gov/vocabulary/targetAudiences.html

[infomnivore]

Based on Rebecca's comment here (and the general philosophical points raised by Ray), my sense is we should modify the XSLT to swap in the id.loc.gov URIs, but, in the standard, allow for the possibility that people will just provide the strings.