hi Richard
Having most permutations in play here we are still finessing our
thinking on this.. but I think I'd say:
- directory and folder structures should be simple and sensible and
considered transistionary (i.e. no other solution is ready so we have
tons of stuff in dir/files structures)
- with that in mind try to encourage various specialists who are
creating this content to use dir/file structures that, like you have
done, can be machine processed later into sensible (very simple)
metadata for import to a DAM, and that make sense in their context (the
specialists), often this means different dir/file schemes for different
work (i.e. conservation vs art photography) to ensure the really
important metadata is there.. if that includes object numbers etc, so be
it.. it's transistionary and must be useable in the interim..
- if there's time.. obviously give these folks lightroom or similar
tools and encourage real metdata creation embedded in the jpgs (xmp,
iptc etc) too, or a lower tech solution.. the creation of a 'sidecar'
spreadsheest which go with the file-set.
The trouble I'm having unravelling open data links for digital assets
relates to another recent thread on MCG around CMS-DAM connections,
where IPR + copyright metadata is, and which system enforces it.. with
that in mind it becomes obvious that *all assets* are not suitable for
true 'open' linked URI treatment.. having said that, there is no reason
why you can't use exactly the same technology and model to run your own
internal 'closed' linked data URI's (for connections/integrations
between systems), and put another 'layer' in front of that
'closed'/private system, that are true 'open' links which have had
enforcement behind the scenes honouring all your rules/policies (IPR,
copyright, publishable, not publishable etc)..
If one goes down this path then the principles of the open data model
kind of dictates that your asset IDs would not contain 'physical object'
object numbers, that would be confusing - the digital asset is an object
in its own right and should have its own unique identifier (sometimes
easier said than done in practice..). The way I generally explain it to
non technologists is to think of the digital assets exactly like you
think of physical objects - each one is an individual thing, needs its
own unique identifier, and its own catalogue record (this analogy
stretches all the way to acquistioning etc too, but thats out of scope..
:-) )
How you glue all this together is "middleware" or integration, or
whatever one likes to call it..
Which is a complete topic on its own, and, I would say, a tech step too
far for some instituions at the moment..
hope this helps
Shaun
The Fitzwilliam Museum
On 09/05/2013 22:45, Richard Light wrote:
> After the last discussion of DAMs on this list :-) , I was enthused to
> write a little CGI program which took a database name, file name and
> primary key as parameters, ferreted around inside the relevant
> database record, and then returned the first image which was
> referenced therein.
>
> This program was written primarily with a view to experimenting with
> dynamic re-sizing of the image (controlled by yet more parameters),
> checking of rights, etc. However, it also raised the possibility of
> adopting a "Linked Data" approach to image access. This involves
> decoupling the physical filename (which you still need to decide upon,
> and to store in your collections database records) from its "logical"
> name. Thus, a collections object might have the Linked Data identity:
>
> http://collections.wordsworth.org.uk/Object/WTcoll/id/GRMDC.C104.4
>
> and its first image would have the identity:
>
> http://collections.wordsworth.org.uk/Object/WTcoll/image/GRMDC.C104.4
>
> [This is not yet working: you just get the HTML view again.]
>
> This rather goes against Angela's advice - I would be interested to
> hear what others think of the idea.
>
> Richard
>
> On 09/05/2013 14:55, Angela Murphy wrote:
>> As for file naming standards - there seem to be as many different
>> examples of file naming as there are collections. In my opinion these
>> should not contain the physical name of an item ( or
>> inventory/accession number) and should follow the maxim - keep it
>> simple.
>
****************************************************************
website: http://museumscomputergroup.org.uk/
Twitter: http://www.twitter.com/ukmcg
Facebook: http://www.facebook.com/museumscomputergroup
[un]subscribe: http://museumscomputergroup.org.uk/email-list/
****************************************************************
|