AC Iptc4xmpExt:CVterm guidance may be inconsistent with IPTC spec

[GoogleCodeExporter]

About http://terms.tdwg.org/wiki/Audubon_Core_Term_List#Iptc4xmpExt:CVterm

In private email about an example he constructed, Steve Baskauf wrote: 
"Probably not using Iptc4xmpExt:CVterm correctly.  I'm using it with a 
URI-value but I'm not sure if it should be a literal.  I'm linking to the 
standard view URIs I've defined, but I don't think that's right either. "

I replied approximately:

I think the AC guidance for this term is somewhere between misleading and 
wrong. We don't specify  which of the several supported implementations in [1] 
we mean to be applicable.  My feeling is that the original MRTG intent for IPTC 
terms was highly motivated by xmp usage.  For that, [1] is unambiguous: the 
value is a bag URI. (I find no definition of "bag" in [1], but that is a minor 
point.) In summary, I think the suggestion in the AC spec that literals can be 
used is simply contradicted by the IPTC spec.  Not to mention that we know what 
problems arise in RDF if a predicate is used with both a URI and a literal. As 
a further aside, [1] happens to specify
   (a) "Required CV Any Controlled Vocabulary registered with the IPTC for this field. "
   (b) "Implementation Note(s) This property is part of the Photo Metadata 2008 specifications, but should not released to the public on the standard Adobe Custom Panels for IPTC metadata or other user
interfaces unless agreed by the IPTC." 

[1] 
http://www.iptc.org/std/photometadata/specification/IPTC-PhotoMetadata-201007_1.
pdf

Original issue reported on code.google.com by morris.bob on 15 Nov 2013 at 6:36

[ramorrismorris]

I believe that from [1] (?) we can conclude that there is always(?) a Iptc URI that has the form of an http URI but is not resolvable. This implies (?) that such each such thing is a literal. See also issue #100 which might support resolvable URIs.

[baskaufs]

Closing this as it is now included in Issue #115