On Sat, 06 Oct 2007 03:37:16 +0200, pkeane <[EMAIL PROTECTED]> wrote:
<dase:admin_mime_type>image/jpeg</dase:admin_mime_type>
<dase:admin_filename>PICA17902.JPG</dase:admin_filename>
<dase:admin_checksum>c837f0abd05c8b7126b8dac15d510f30</dase:admin_checksum>
<dase:admin_file_size>787705</dase:admin_file_size>
<dase:admin_image_width>1408</dase:admin_image_width>
<dase:admin_upload_date_time>2007-07-18T15:59:19</dase:admin_upload_date_time>
<dase:admin_serial_number>000435205</dase:admin_serial_number>
<dase:admin_image_height>1209</dase:admin_image_height>
<texpol:keyword>Congress Avenue</texpol:keyword>
<texpol:keyword>buildings</texpol:keyword>
<texpol:scratch_pad>/PICA17902.JPG</texpol:scratch_pad>
<texpol:rights_owner>Austin History Center</texpol:rights_owner>
<texpol:rights_status>Use in Texas Politics
content</texpol:rights_status>
<texpol:credit>Photographer: Unknown</texpol:credit>
<texpol:dase_rights>Restricted</texpol:dase_rights>
<texpol:original_filename>PICA17902.JPG</texpol:original_filename>
<texpol:used_in_chapter>executive</texpol:used_in_chapter>
If you could document these fields and their usage in the consuming
application, it would be easier to devise a way of encoding them in a more
Atom-friendly way.
As to your current implementation, why is 'dase:admin_mime_type' needed
when you have 'atom:content/@type'? Can't 'texpol:rights_owner',
'texpol:rights_status' and 'texpol:dase_rights' be implemented with
'atom:rights' or '[EMAIL PROTECTED]'copyright']' (or both)?
Can't 'texpol:original_filename' be an 'atom:link' with an appropriate
'@rel' and a working (dereferencable) '@href'? The same goes for
'texpol:used_in_chapter', 'dase:admin_filename' and 'texpol:scratch_pad'.
I'm sure Dublin Core can help out with proper relationships here.
If you can use the Dublin Core elements directly, do that. I'm thinking
that 'dase:admin_upload_date_time' has the same semantics as 'DC:
Created'; <http://dublincore.org/documents/dcmi-terms/#created> and thus
can safely be replaced with that element.
'texpol:keyword' - can't 'atom:category' be used here?
When excersising all of the changes I propose above (assuming all of them
can be done successfully), you end up with a lot less extension elements
and a much more interoperable format. The stuff left is really just
metadata about the physical properties of the image (height, width, size)
that can be stuffed into one extension element.
--
Asbjørn Ulsberg -=|=- [EMAIL PROTECTED]
«He's a loathsome offensive brute, yet I can't look away»
