search

SAA-SDT / EAD3

https://www.loc.gov/ead/index.html
Creative Commons Zero v1.0 Universal
86 stars 25 forks source link

Add @encodingAnalog to <part> #82

Closed rockivist closed 11 years ago

rockivist commented 11 years ago

In response to feedback from Kate Bowers on the EAD list (2013-03-19), I think we should add @encodingAnalog to the <part> element.

MicheleCombs commented 11 years ago

Strongly agree. One of the main drivers behind adding was to allow encoding of MARC subfields; if we don’t have encodinganalog we aren’t fully supporting that goal.

Michele

From: Michael Rush [mailto:notifications@github.com] Sent: Wednesday, March 20, 2013 11:32 PM To: SAA-SDT/EAD-Revision Subject: [EAD-Revision] Add @encodingAnalog to (#82)

In response to feedback from Kate Bowers on the EAD list (2013-03-19), I think we should add @encodingAnalog to the element.

— Reply to this email directly or view it on GitHubhttps://github.com/SAA-SDT/EAD-Revision/issues/82.

anarchivist commented 11 years ago

I am pretty neutral whether we add encodingAnalog to <part/>, but I disagree with @MicheleCombs regarding not fully supporting that goal, given that it also has a localType element which allows for more robust crosswalks to be defined.

MicheleCombs commented 11 years ago

True, but localType is totally generic while @encodinganalog is specifically for mapping to other encoding systems, which I think is totally appropriate here. The attribute is present in many other EAD elements, including the parent elements of part itself; seems to me only logical to also allow it in part. Otherwise we essentially force people to use two different attributes for the same type of data (encodinganalog in some places and localType in others). To me that seems not only annoying, but non-optimal design.

From: Mark A. Matienzo [mailto:notifications@github.com] Sent: Thursday, March 21, 2013 10:15 AM To: SAA-SDT/EAD-Revision Cc: Michele R Combs Subject: Re: [EAD-Revision] Add @encodingAnalog to (#82)

I am pretty neutral whether we add encodingAnalog to , but I disagree with @MicheleCombshttps://github.com/MicheleCombs regarding not fully supporting that goal, given that it also has a localType element which allows for more robust crosswalks to be defined.

— Reply to this email directly or view it on GitHubhttps://github.com/SAA-SDT/EAD-Revision/issues/82#issuecomment-15240771.

anarchivist commented 11 years ago

I understand your point; my concerns about encodingAnalog are certainly larger than this specific case.

dpitti commented 11 years ago

The rationale for localType in EAC-CPF is that it subsumes encodingAnalog.

And I note that there was a request for @localTypeSource to accompany it, but this is unnecessary if the @localType is anyURI, wherein the source of the vocabulary and the vocabulary term are expressed in the URI.

rockivist commented 11 years ago

If we continue to include @encodinganalog, I think <part> is a good place to have it. That said, Daniel raises the larger issue, which is whether or not we should globally replace @encodinganalog with @localType. Thoughts? I'm on the fence, leaning toward eliminating @encodinganalog in favor of @localType. I'd like a consensus here before vetting with TS-EAD. I need a clear justification, which I can't articulate myself. at the moment.

svassallo commented 11 years ago

I agree with Daniel. I think that the main justification is that we can't provide an official, clear vocabulary for @encodingAnalog... I think it's similar to the decision "change name of all type attributes WITHOUT associated value list to "localtype"" because here we can't define a value list.

just my 2c (of euro)

anarchivist commented 11 years ago

I agree with @dpitti and @svassallo because of the fact that @encodingAnalog is uncontrolled.

Generally speaking I would advocate for @localTypeSource for cases where @localType is not a URI.

MicheleCombs commented 11 years ago

The relatedencoding attribute specifies the vocabulary to be used for encodinganalog -- doesn’t that make it controlled, at least to some degree?

From: Mark A. Matienzo [mailto:notifications@github.com] Sent: Tuesday, March 26, 2013 9:36 AM To: SAA-SDT/EAD-Revision Cc: Michele R Combs Subject: Re: [EAD-Revision] Add @encodingAnalog to (#82)

I agree with @dpittihttps://github.com/dpitti and @svassallohttps://github.com/svassallo because of the fact that @encodingAnalog is uncontrolled.

Generally speakin I would advocate for @localTypeSource for cases where @localType is not a URI.

— Reply to this email directly or view it on GitHubhttps://github.com/SAA-SDT/EAD-Revision/issues/82#issuecomment-15458261.

MicheleCombs commented 11 years ago

For what it’s worth, we have allowed other things to survive this revision (i.e., stay in EAD) because they were relatively harmless, and because the change would have had a major impact on the user community. Seems like encodinganalog falls into that category. Doesn’t seem like it wouldn’t hurt anything to leave it in, and I suspect that it’s in wide use in the user community. Kathy’s tag usage report showed that 98% of the finding aids used relatedencoding and 358,000 instances of encodinganalog – more than any other attribute except type – which seems to support this..

Michele

From: Michael Rush [mailto:notifications@github.com] Sent: Monday, March 25, 2013 10:06 PM To: SAA-SDT/EAD-Revision Cc: Michele R Combs Subject: Re: [EAD-Revision] Add @encodingAnalog to (#82)

If we continue to include @encodinganalog, I think is a good place to have it. That said, Daniel raises the larger issue, which is whether or not we should globally replace @encodinganalog with @localType. Thoughts? I'm on the fence, leaning toward eliminating @encodinganalog in favor of @localType. I'd like a consensus here before vetting with TS-EAD. I need a clear justification, which I can't articulate myself. at the moment.

— Reply to this email directly or view it on GitHubhttps://github.com/SAA-SDT/EAD-Revision/issues/82#issuecomment-15436986.

svassallo commented 11 years ago

@MicheleCombs is almost the same with the pair @localType / @localTypeSource (or info expressed in the URI)... in this sense every @localType is controlled...

My only concern is if there is a use case in <part> (or other element) where we want to express both encoding analog and an other local type information.

I'm not sure that using '@localType` instead of '@encodingAnalog' is a major change... for old EAD documents is similar to a name change

tcatapano commented 11 years ago

I think there are good arguments on both sides, but FWIW I feel that @encodingAnlalog carries a different intention than @localType. An @encodingAnalog is more like a sameAs or closeMatch assertion whereas localtype is more an isA assertion. So @encodinganalog="marc651" and @localType="http://www.loc.gov/mads/rdf/v1#Geographic" or localType="http://dbpedia.org/ontology/country" is saying the <ead:part> text node is a Geographic term/country and that the element is a close match/same as/analogous to a MARC 651 field. The problem is the semantics are really applied at the instance and processing end, not in the schema, so users are going to make use of @localType in various ways. At the very least having both @encodingAnalog and @localType give two syntactic hooks on which to hang different semantics. But I do think it can be easily understood that the schema's intended semantics for encodingAnalog is different and narrower than @localType.

tcatapano commented 11 years ago

Implemented. Closed