make work member of att.authorized

[rettinghaus]

Almost every element within <work> is part of att.authorized, but not <work> by itself.
(The idea of a "work" is known to authorities http://viaf.org/viaf/176603722)
Especially for meta-data exchange it seems to be important to have instead of using <identifier>.

[pe-ro]

It seems to me that it's the work identifier that's authorized, not the work itself, so work, expression, manifestation (source), and item aren't members of att.authorized. Making them members of this class and removing <identifier> takes away the possibility of referring to more than one authority, of which there are currently several that could be used. Not removing <identifier> creates the possibility of putting the same info in two different places. So, at this point in time, I think it makes more sense to leave well enough alone, even if it's not absolutely correct.

[rettinghaus]

I don't think so. Following this argumentation, persons and works are treated totally different when it comes to authority data. <identifier> is allowed in <work> and <persName>, but also the latter is part of att.authorized. So would you say that in this case att.authorized is used to authoritze the spelling of the persons name and then you have to identify the authority with an <identifier> to be authorized? And is it just the name that gets authorized by the authority? I always thought the other way around: the authoriy make sure the person is identified correctly whatever the name is actually written.
And saying "the possibility of referring to more than one authority" is needed, but fearing simultaneously "the possibility of putting the same info in two different places" doesn't makes too much sense. Normally you would use one authority throughout a project (e.g. VIAF). And if you really want to remove double-encoding possibilities from MEI we should start again with it from ground up.
Personally I would use <identifier> to encode catalogue information like BWV 233 (like MerMEId does). Using att.authorized on this would IMHO not say anything about the work itself but merely about the used catalogue raisonné (e.g. edition).

[pe-ro]

I'd be interested in hearing what Axel has to say on this topic, but it seems he's not a participant in Github. Would you mind soliciting input on the metadata interest group's list -- mei-catalog-ig-bounces@lists.uni-paderborn.de?

[rettinghaus]

At first we may point @axgeertinger to this issue and then carry it over to the list.

[pe-ro]

Ah, just so. I couldn't find an ID for him. Thanks.

[axgeertinger]

Thanks for inviting me to the discussion :-)

It seems we want to deal with two types of authorization: 1) authorizing the spelling of a name (whether work, place, person etc.) and 2) pointing to an authority for disambiguation of the person or work itself regardless of spelling.
The guidelines are not overly clear on this matter. @authority is described as 'A name or label associated with the controlled vocabulary from which the value is taken'. What does 'value' refer to? The content of the element or the value of @codedval? Referring to the element's content would make sense if I want to authorize the spelling of a name or a title. @authority referring to @codedval suggests to me more the disambiguation by pointing to an authority like VIAF. In that case the spelling does not need to be the authorized one (I guess that's the point of pointing to authority files...).

I see Klaus' point, but perhaps <persName> and <work> are not directly comparable. <persName> usually does not encode anything but a person's name (even if quite a number of child elements are allowed); the equivalent element for a work would be <title> which actually is a member of att.authorized and, by the way, may contain roughly the same elements as <persName>, so they are comparable. I admit that we do not have a <person> element, which would be the person's equivalent to <work>, so the situation is not exactly the same. Perhaps that only emphasizes that it is difficult to explicitly encode the authorized identification of a person, not just authorize the spelling of a person's name. Pointing to the person is done indirectly by pointing the person's name to VIAF or some other authoriy file. In my opinion that works pretty well in practice.

When it comes to works, I tend to agree with Klaus that the way to associate a work with VIAF is less obvious, but I am not sure about the best solution. One existing option is to point the work's title to VIAF. That would be exactly the same as pointing a person's name (and not the person) to VIAF, but since we do have a <work> element, trying to use <title> for authorization might suggest that we only want to authorize the spelling of the title.
The other option would be to use <identifier>. Now I can't talk around it any longer: Frankly, I don't understand how to use authorization on <identifier>. That's why MerMEId currently doesn't offer authority information on <identifier>. How is it supposed to be used? @codedval obviously would be expected to contain the work's VIAF ID. But @codedval is described in the guidelines as 'a value that represents or identifies the element content'. Then what is supposed to be the content of <identifier>? When using <identifier>, the coded value does not identify or represent the element´s content but its parent element. And in that case the authorization attributes on <identifier> already contain all the information I wanted to encode, but if I leave <identifier> empty there is nothing @codedval can identify or represent as required by the guidelines. Making <work> a member of att.authorized would solve that problem. But I'd like us to discuss it before making any recommendations.

[axgeertinger]

Perhaps Kristina has something to say? I wanted to mention her but couldn't find her here.

[rettinghaus]

Should we bring it to the list now or wait for November?

[axgeertinger]

Bring it to the list, I'd say. In November (if you are thinking of the workshop in Mainz) we probably should focus on use cases and metadata profiles rather than discussing schema or guideline changes.

[pe-ro]

First, @codedval can't appear on <identifier>, as the latter is not a member of att.canonical.

Second, @codedval always refers to the content of the element to which it's attached. Its most frequent use is probably on <perfRes>. For example,

<perfRes codedval="wa" count="2">2 Flutes</perfRes>

@codedval and @count together constitute an alternative representation of the string "2 Flutes". @codedval is not to be taken too literally; that is, technically it represents the string "Woodwinds - Flute" in the MARC Instruments and Voices Code List. This is not unlike the situation that might occur when coding for gender, where the coded value "m" can represent the textual values "male", "man", "men", etc.

The relationship between @codedval and @auth.uri is admittedly ambiguous. On elements that employ @codedval, the value of @auth.uri is likely to point to the source from which @codedval is taken. For elements that don't use @codedval, @auth.uri refers to the string value of the element. I don't think there's an easy way to resolve this ambiguity. Each project should decide whether to encode string values or coded values and enforce the decisions with schema modifications or Schematron.

Finally, on topic at last, I see the value in making the FRBR entities (work, expression, source, and item) members of att.authorized. The consequence of doing so, however, is likely to lead to more confusion, not less. Traditionally, librarians have authorized string values with other string values; that is, "Roland, Perry D. (1959-)" is the authorized value for "Perry Roland", "P. Roland", "Perry D. Roland", etc. Linked data (which is the principal behind adding att.authorized to the FRBR entities, I think) is a different animal. It asserts that "http://authority.path.info/12345#" is the canonical reference not just to my name, but to me as a person. Just another "thing" on the IoT.

There is room for both approaches. But the practical implications of making these elements members of att.authorized are:

• authority-pointing info can be of either kind and
• it can reside in multiple locations, for example, on <work> or on a <title> descendant of <work>.

With these caveats in mind, I'm willing to make the FRBR elements members of att.authorized. Like several other points in MEI, the encoder will have a choice of how to encode, but must accept the responsibility of clear and consistent practice.

We might also investigate the possibility of using an attribute for linked data on the FRBR elements other than @auth.uri. The intention would be to make clear the difference between so-called "traditional authority data" and "linked data".

[pe-ro]

I want to clear up confusion on the use of @auth, @auth.uri, and @codedval. I see these attributes as a continuum; that is, if all that's desired is identification of an authority, then @auth is the right attribute. For example --

<persName auth="LC Name Authority File">Johannes Kepper</persName>

Going a bit further, one can add @auth.uri to create a follow-able link --

<persName auth="LC Name Authority File"  
auth.uri="http://id.loc.gov/authorities/names/no2005107771">Johannes Kepper</persName>

This is fine when every entity in a thesaurus/ontology/etc has it's own URI. Dealing with so-called linked data can stop here. But, when the URI is provided only to the list level, additional information is needed. For example --

<perfRes auth="MARC Instruments and Voices Code List" 
auth.uri="https://www.loc.gov/standards/valuelist/marcmusperf.html" 
codedval="wa" count="2">2 Flutes</perfRes>

Now, these attributes (auth, auth.uri, and codedval) work independently of each other. For example, the following markup, while somewhat ambiguous, is perfectly acceptable short-hand for the previous example --

<perfRes codedval="wa" count="2">2 Flutes</perfRes>

HTH.

[pe-ro]

I've attached a straw man schema that makes <work>, as well as <expression>, <source>, and <item>, members of att.authorized. It also contains revisions to the descriptions of @auth, @auth.uri, and @codedval in an attempt to reduce confusion.

latest_DEV.txt