Serialization Provenance missing

[GoogleCodeExporter]

Patrick Sweeney reports a need of the New England Vascular Plants project  to 
represent a checksum in AC data.  

This sounds like a need for some provenance attribute in the Access Point 
Vocabulary.

Original issue reported on code.google.com by morris.bob on 26 Feb 2013 at 5:25

[GoogleCodeExporter]

Original comment by morris.bob on 26 Feb 2013 at 5:26

• Added labels: Type-Enhancement

[GoogleCodeExporter]

Original comment by morris.bob on 26 Feb 2013 at 5:27

• Added labels: Component-Terms

[GoogleCodeExporter]

In addition to representing the checksum value, some way is needed to represent 
the checksum procedure/algorithm used to generate the value (e.g., MD5, SHA1, 
etc.).

Original comment by sweeneyp...@gmail.com on 5 Mar 2013 at 2:14

[GoogleCodeExporter]

1. Is this meant to be a checksum on data available from an access point? If 
yes, do we need to support both a checksum method and a checksum value as 
access point properties? Or is it sufficient to fix one, say MD5, and just 
support the value.  My inclination is that adding both attributes is not 
onerous, and we could even declare a default.

2. Certainly(?) your intent was not to put a checksum of a serialized record in 
that serialized AC record. Such a thing would have to be outside the 
serialization and so a concern of the producer of the serialization and not of 
the representation-free AC spec under review here.

Original comment by morris.bob on 5 Mar 2013 at 2:39

[GoogleCodeExporter]

It is meant to be a checksum on data (an image) available from an access point. 
From the standpoint of our project, it would be sufficient to fix one (MD5).

Our intent is not to represent a checksum of the record itself.

Original comment by sweeneyp...@gmail.com on 18 Mar 2013 at 2:50

[GoogleCodeExporter]

I support adding this as an attribute on an AccessPoint.  We could also supply 
a URI for the nature of the checksum. It possibly gets complicated if we allow 
more than one pair per AP, but this is a typical issue about multiplicity, so I 
also support making it be one per AP.

Original comment by morris.bob on 18 Mar 2013 at 5:22

[GoogleCodeExporter]

I have added terms hashType and hashValue (labels "Hash Type" and "Hash"). 

Original comment by morris.bob on 8 Jun 2013 at 2:21

• Changed state: Fixed
• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

I propose hashFunction or hashAlgorithm instead of hashType (unusual and 
strictly speaking wrong). This would also help possible confusion with 
misinterpreting hash value as an xml fragment identifier (= after the hash 
character in a URI).

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

[GoogleCodeExporter]

Changed to hashFunction

Original comment by morris.bob on 30 Jun 2013 at 7:48