Should ac:accessURI be repeatable?

[GoogleCodeExporter]

1. Provide an ac Term Name or Label. 
ac:accessURI 
http://terms.gbif.org/wiki/Audubon_Core_Term_List_%281.0_normative%29#accessURI

2. Describe the defect or lack of clarity you find in the term. 
From Alexey Zinovjev: Are you sure that this should not be repeatable? I have a 
feeling that just this is a case when you could have more than a single URI 
leading to the same resource. The most common example on the web is a 'www' 
prefix, which frequently could be omitted. And how about mirroring? 

Original issue reported on code.google.com by steve.ba...@vanderbilt.edu on 6 Apr 2013 at 2:33

[GoogleCodeExporter]

Needs some discussion to decide if doing so would run afoul of our desire to 
have a nearly flat implementation always be possible.

The examples of www prefix and mirroring are not entirely convincing, since 
they are typically implemented with server-side mechanisms, and for good 
reason.  For example, if a mirror URL were explicitly given and that mirror 
ultimately became dead without any redirection, then there is now an existing 
AC record possibly in the world that is advertising a dead accessURI. 
Implementers might choose to recommend or enforce that once defined, a metadata 
record with a given dc:identifier must remain unchanged, and then it becomes a 
matter of issuing an entire new record.  AC is silent on these serialization 
questions, but it seems to me that in general that Alexey's case is more often 
when the creator of the AC record wants a static second accessURI for a single 
accessPoint.

All that said, at the moment it seems harmless to make it be repeatable.

Original comment by morris.bob on 3 Jun 2013 at 10:06

• Added labels: Priority-Critical, Milestone-Release1.0

[GoogleCodeExporter]

I vote against making this repeatable. The use cases are rare and not worth the 
confusion of having to interpret the semantics of multiple URIs, and what rules 
to follow in such a case.

The example "The most common example on the web is a 'www' prefix, which 
frequently could be omitted." should be solved by the provider, making one the 
canonical, the other the deprecated but redirected URI. There is no need to 
record deprecated URIs in AC document. The other consideration "mirroring" is 
certainly a valid use, but it is still doubtful whether AC needs to support 
fallback mechanisms that first try one URI and when failing, after timeout, try 
others.

Original comment by g.m.hage...@gmail.com on 4 Jun 2013 at 8:44

[GoogleCodeExporter]

I concur and am resolving this as WontFix.

Original comment by morris.bob on 4 Jun 2013 at 11:24

• Changed state: WontFix

[GoogleCodeExporter]

Original comment by morris.bob on 4 Jun 2013 at 11:26

• Removed labels: Priority-Critical

[GoogleCodeExporter]

Original comment by morris.bob on 22 Oct 2013 at 1:53

• Added labels: Type-Enhancement