I’m using Omeka to annotate audio collections which are stored on another (archival institution webserver). So i actually have a link to eg an mp3 file.
When using such link as Media, using the URL as source, Omeka nicely pulls a copy, and creates a copy in a browser-suitable access format.
However, I do NOT want Omeka to pull a copy of those files on my server, since this is supposed to be metadata-only, nor transcode it - since it’s already mp3
Is there a way that I can have the mp3 link as property-value, and have a web-player load that /remote/ audiofile?
Unless you’ve got some interesting module for that purpose (and I’m not aware of any), then there’s no transcoding happening for MP3s. They’re just getting copied over as-is.
I don’t think we have any out-of-the-box way to only “hotlink” media like that, to serve it totally remotely. There are some media types that work that way (like oEmbed or Youtube), or you could make an HTML media and have the HTML just be a link to the remote file.
Regarding mp3 transcoding not happening: fine.
I was assuming Omeka created access copies.
I’ve seen the Youtube and oEmbed Media option. I’ve tried the HTML workaround you’ve suggested - but this is less practicle than just adding the plain link as URI of a property like “schema.org:audio” (for example).
Hm… If I come up with a nice solution, I’ll post it here
Thanks!
Oh yeah, and you could do that also: just add the link as a property value. Didn’t think to mention that but that’s the simplest way to add a link, certainly.
Hi, I would edit the template common/resource-values.phtml of the theme and modify the HTML output for the property with the term schema.org:audio to include a audio tag.
@boregar: +1!
That’s exactly what I was about to do!
I’m already digging in to Theme-Developer documentation, trying to find a class-documentation which PHP variable/property holds the item’s “schema.org:audio” type string?
When I tried to var_dump() $value or $property, I get a " Fatal error*: `Allowed memory size of 268435456 bytes exhausted (tried to allocate 132124672 bytes)"
Which is odd, as the 2nd number is smaller than the 256 MB limit.
I remember having read somewhere that I could easily get the API link for the current item somehow in the theme?
Anyone could point me to where I can find the right class definition for an item object accessible in common/resource-values.phtml?
Trying to var_dump our database objects can cause this kind of problem: there’s a lot of interconnected objects you’ll be dumping if you do that.
common/resource-values.phtml loops over all the values for a resource to display them all, so everything you need is already accessible there. The part of that file that prints $value->asHtml() is what displays each value.
The data you probably would want to look at to make your change:
$property->term() is the term string for the current property being printed (i.e. schema:audio or dcterms:title, etc.).
$value->uri() is the URI for the current value being printed.
…okay I admit it’s a quick-hack, but I now use $property->term() to check if it’s schema:audio- and then check if the $value->uri() starts with a certain domain, and then insert the appropriate/matching player code, or a plain
Will look at modules: If starting with an existing (skeleton) model code, it might be a nice add-on for metadata-only setups of Omeka S
@jflatnes : Thank you for the $property and $value code hints. Where can I find the documentation on the class properties/methods? (source looks like I could run doxygen on it :))
With a module, you could either do this approach (using a filter to change how the value is displayed) or probably more straightforwardly just add a “remote audio/video/media/whatever” media type. You could have a media that takes the URI and just saves that and renders the audio tag pointing to the remote media. The plus with doing it that way is that it will be usable anywhere else media gets used, like embedded on a site page or something like that.
The API “representations” part of the dev docs is where this type of thing should be, for what you can call on the property and value, etc., but I don’t think we’re currently listing that nicely. A simple table of the representations and their methods is probably worth having.
We don’t have doxygen/phpdoc/whatever pre-ran on the code but yes, you could do that, or load it up into an IDE or whatever, yeah.
I’ll see if I can identify the property/value classes for item metadata running Doxygen on Omeka’s source.
As you describe it, turning the “hack” into a proper module patch sounds way cleaner, nicer - and actually maintainable
Let’s hope budget allows to allocate time for that.
Do you have a contact list of developers who’re experienced with building Omeka modules, and may be available for hire?
I’ve read and studied The API Representations Docs up and down, yet for example “$property->term()” ain’t mentioned there: so how could I have known?
I’m amazed how stable and consistent Omeka S is performing (=my first setup), as I’m experienced with many different web-based collection asset management and workflow systems: Kudos! Great work!
Even having loaded quite many modules, I’m still not experiencing any clever-spaghetti-hack oddities. Awesome. Fell in love with RDF thanks to Omeka S (and Wikidata).
btw: I find it a bit confusing that the “Representation” docs mention the variable $item, whereas I could not find documentation on the variables $property and $value, used in the theme templates.
Thanks for any clarification and pointer to proper docs or source code.
