feature request #9067
closed
[DISCUSS] Allow media to support external links not being files
Added by Andreas Müller almost 4 years ago.
Updated about 3 years ago.
Description
The current handling of media expects that links stored in Media(RepresentationPart) are media files or can be opened in Universal Viewer.
Often links to Media can only be stored as links to Websites (e.g. html). Websites can not be displayed in Universal Viewer usually (correct?).
If this is the case we need to decide how we want to store such data.
Possible solutions are:
- keep everything as it is, the link will be stored in MediaRepresentationPart and MimeType will be set to "HTML" or "unknown" (TODO check correct MIME types), an application needs to decide what to do if we have this MIME type;
- Pro: nothing to change in model,
- Con: we have to change the handling for unknown MIME type, currently it is handled as xxx
- Use Media.links to store URLs which are not files
- Pro: nothing to change in model
- Con: not intuitive, unexpected usage of IdentifiableEntity.links
- Add Media.link of class ExternalLink to distinguish file based representations from Websites
- Pro: it is possible to distinguis from the datastructure if Media should be represented as link or as Image/Movie/Sound
- Con: new field, semantic overlap with MIME type, need to disallow to fill both fields "links" and "representations"
- Same as 3. but having a common base class MediaBase and 2 subclasses Media and LinkedMedia
- Pro: possible to distinguish from class what reprentation is required; easy to develop specialised TaxEditor UIs; further attributes can be removed from LinkedMedia; MediaKey and PhylogeneticKey could be handled as spearate subclasses of MediaBase, currently it is a subclass of Media
- Con: new field; semantic overlap with MIME type; switching from one type to the other is bit more difficult; need to adapt existing code to use Media or MediaBase depending on context
- % Done changed from 0 to 10
I preliminary added an attribute link (ExternalLink) to Media class to be able to immediately support solutions 3 or 4 if we will decide for them
- Status changed from New to In Progress
I actually see no benefit of the "solutions" 2 - 4 over 1.
Adding additional fields for external links is nothing else than adding a representation with the mimetype text/html. This new idea only gives users two options for adding links which opens a new source of erroneous usage of the data model. We will need to check the content type anyway in order to prevent users from adding links to "image files" as external link. I don't see that we would win anything by this model change but a more complex model.
Considering these options we should not think of links to image files and other links as this is missleading. In terms of ULRs it is only possible to distinguish between files and non files by the protocol part of the URL: file:/// vs. http://. A http url which ends to with something like .../Uh76Z.jpeg strongly suggests that you will get an jpeg image. Another url .../Uh76Z.do, .../Uh76Z may also deliver an image. There is no way to be sure except 1) trusting the server and doing an HTTP GET or HEAD request and read the Content-Type header or 2.) as last resort to download the response object and examine it.
WGB:
als Diskussionsbeitrag der Hinweis, dass wir in der Darstellung im Portal grundsätzlich die Unterscheidung einer Darstellung als Link (URL-Text) und als Zugriff (Bild oder andere Media-Darstellung) haben, und dass das die Form der Darstellung eine editorische Entscheidung für die betreffende Instanz ist. Bei der Druckausgabe handelt es sich bislang ausschließlich um die Ausgabe von Links als Text. In jedem Fall unterscheiden sich diese Links von den automatisch gesetzten (im Block im Portal) dadurch, dass sie von jemandem revidiert wurden, also Teil des taxonomischen Treatments sind.
Bei den Links gibt’s dann noch die Unterscheidung zwischen den auf beliebige Websites und den (hoffentlich) permanent aufgelösten, auch den, die hinter permanenten IDs wie den derzeit verwendeten DOI, CETAF-IDs, IPNI, Tropicos, BHL, JStor Plants stehen. Des weiteren können die definierten Links natürlich noch nach Inhalt klassifiziert werden, also Specimen IDs (heute: CETAF, Tropicos, US-National Herbarium etc.), digitales Druckwerk (BHL, Madrid, Gallica, ....), Name (Tropicos, IPNI).
- Target version changed from CDM UML 5.15 to CDM UML 5.43
- Status changed from In Progress to Closed
- Target version deleted (
CDM UML 5.43)
- % Done changed from 10 to 100
Andreas Kohlbecker wrote:
I actually see no benefit of the "solutions" 2 - 4 over 1.
Adding additional fields for external links is nothing else than adding a representation with the mimetype text/html. This new idea only gives users two options for adding links which opens a new source of erroneous usage of the data model. We will need to check the content type anyway in order to prevent users from adding links to "image files" as external link. I don't see that we would win anything by this model change but a more complex model.
Considering these options we should not think of links to image files and other links as this is missleading. In terms of ULRs it is only possible to distinguish between files and non files by the protocol part of the URL: file:/// vs. http://. A http url which ends to with something like .../Uh76Z.jpeg strongly suggests that you will get an jpeg image. Another url .../Uh76Z.do, .../Uh76Z may also deliver an image. There is no way to be sure except 1) trusting the server and doing an HTTP GET or HEAD request and read the Content-Type header or 2.) as last resort to download the response object and examine it.
I agree. Probably solution 1 is enough to handle this. Only the TaxEditor (or which ever editing tool) should clearly distinguish for the user if something is expected to not be showable in a Viewer. E.g. by showing a warning that a link can not be shown in an image gallery.
This should be easily possible as Media are now only used for "real" media while e.g. links to protologues are handled as external links only (such links are expected to not be files but websites by default).
So I close this ticket and open 2 new ones for correct handling of "html-based" in TaxEditor and data portal. For print publication it is not needed, I think, as print publications always show links only.
- Copied to feature request #9547: Show warning in TaxEditor if a MediaRepresentation can not be shown in a Viewer added
- Related to feature request #9548: Handle links to websites, webapps or similar in image galleries (simple and UV) added
- Related to bug #9775: Open issues for web app media in the image gallery added
- Related to feature request #3630: Taxeditor should add mimetype of mediaRepresentations automatically added
Also available in: Atom
PDF