Classification

[melanieWacker]

This continues a discussion started under issue 6: https://github.com/blunalucero/MODS-RDF/issues/6

The MODS XML element may contain either the classification number only or the entire call number. So we could encounter values that can be easily swapped out for a URI since both Dewey and LC are available as linked data (http://dewey.info/ and http://id.loc.gov/authorities/classification.html), and others that may have to be preserved as a string.

Current MODS RDF specifications (from MODS RDF Ontology Primer):

For a MODS classification, RDF representation depends on whether or not the classification scheme is a term in a known vocabulary. Classification scheme from a Known Vocabulary

If the classification scheme belongs to a known vocabulary, classification is treated as described by RDF Property a Vocabulary Term:

{MODS resource} class:{scheme} {classification} Where ‘class:’ is the prefix for the class scheme vocabular. Example:

ModsResource12356 class:lcc ‘HE380.8’

Where ‘class:’, in this example, is the prefix for the URI http://id.loc.gov/vocabulary/classSchemes Classification scheme not from a Known Vocabulary

A classification where the scheme is not part of a known vocabulary is treated as described in Type and Value Bound Together. It is desribed by a triple of the following form: {MODS resource} classificationGroup {ClassificationGroup}

where {ClassificationGroup} groups together a classification and its scheme. Example:

ModsResource12356 classificationGroup #BlankNodex

BlankNodex rdf:type ClassificationGroup

BlankNodex classificationGroupScheme ‘xyz’

BlankNodex classificationGroupValue ‘HE380.8’

[melanieWacker]

This was last discussed on the May 20th Working Group call with a note to revisit "later on": https://github.com/blunalucero/MODS-RDF/wiki/MODS-RDF-Working-Group-Call-5.20.14 See also example of the current MODS RDF conversion: http://www.loc.gov/standards/mods/modsrdf/examples/0017.rdf http://www.loc.gov/standards/mods/modsrdf-primer-2.html#classification

BIBFRAME has defined subproperties specifically for DDC, LCC, NLM, and UDC http://bibframe.org/vocab/classification.html

1) Do we generally agree with the approach currently taken by MODS RDF? 2) Allow for literals or URIs since the MODS XML element may contain either the classification number only or the entire call number? 3) Establish best practice going forward to use classification for the actual class number and shelfLocator for the call number?

[raydAtLC]

There has been recent discussion within BIBFRAME about some of the “types” that we currently treat as properties, instead treat them as classes. ( And for this discussion I’m considering classification scheme as a type.) I think we should discuss this approach.

So for example:

http://example.com/xyz/modsResource123 modsrdf:classification [ a modsrdf:DdcClassification ; rdf:value "234.5" . ] .

Here the class DdcClassification expresses the classification scheme. The property, classification, just expresses that it is a classification but doesn’t express the scheme.

The advantage of this approach is that the resource – the ddc classification – could exist outside of MODS RDF, and it would express its classification scheme, whereas using the alternative approach ….

http://example.com/xyz/modsResource123 modsrdf:ddcClassification [ a modsrdf:Classification ; rdf:value "234.5" . ] .

…. Here, the classification resource itself does not indicate the classification scheme and it can only be revealed in the context of MODS RDF. (This is supposed to be a linked data feature, that a resource, such as a classification, can be re-used.)

[melanieWacker]

See Working Group notes from Nov. 7, 2014: https://github.com/blunalucero/MODS-RDF/wiki/MODS-RDF-working-group-call-11.7.14

[infomnivore]

So, to summarize the discussion to this point: we agree that the classification types should be treated as classes rather than properties.

I am still unclear whether we agreed use the label "classification" or "hasclassification": it sounded from the notes like there was a preference for the former, but I wasn't sure, since some of you seemed to think that the latter is more in keeping with RDF labeling practices.

[raydAtLC]

I honestly don’t think there is a coherent “best practice” for this. Looking at BIBFRAME property names, there doesn’t seem to be a consistent pattern. I don’t have a strong preference. I think perhaps the only time it matters is when there are inverse properties. For example, a BIBFRAME work indicates an instance of that work via property hasInstance, and the instance indicates what work it derived from via property instanceOf. However my preference would have been to omit the ‘has’ and go with the two properties instance and instanceOf. For classification none of that is applicable. I suggest not using ‘has’ at all, but I really don’t care strongly either way.

Ray

From: Rob Hilliker [mailto:notifications@github.com] Sent: Tuesday, November 18, 2014 10:55 AM To: blunalucero/MODS-RDF Cc: Denenberg, Ray Subject: Re: [MODS-RDF] Classification (#15)

So, to summarize the discussion to this point: we agree that the classification types should be treated as classes rather than properties.

I am still unclear whether we agreed use the label "classification" or "hasclassification": it sounded from the notes like there was a preference for the former, but I wasn't sure, since some of you seemed to think that the latter is more in keeping with RDF labeling practices.

— Reply to this email directly or view it on GitHubhttps://github.com/blunalucero/MODS-RDF/issues/15#issuecomment-63492480.