Project

General

Profile

Actions

feature request #9067

closed

[DISCUSS] Allow media to support external links not being files

Added by Andreas Müller over 1 year ago. Updated 10 months ago.

Status:
Closed
Priority:
New
Category:
cdm
Target version:
-
Start date:
06/12/2020
Due date:
% Done:

100%

Estimated time:
Severity:
normal

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:

  1. 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
  2. Use Media.links to store URLs which are not files
    • Pro: nothing to change in model
    • Con: not intuitive, unexpected usage of IdentifiableEntity.links
  3. 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"
  4. 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

Related issues

Related to Edit - feature request #9090: Implement external links for identifiable entities in TaxEditorNewKatja Luther06/23/2020

Actions
Related to Edit - feature request #9545: Remove "External Link type" completelyClosedKatja Luther03/24/2021

Actions
Related to Edit - feature request #9546: [DISCUSS] Merge ExternalLink and MediaRepresentationNewAndreas Müller03/24/2021

Actions
Related to Edit - feature request #9548: Handle links to websites, webapps or similar in image galleries (simple and UV)NewAndreas Kohlbecker03/24/2021

Actions
Related to Edit - feature request #9064: Add ExternalLinks to IdentifiableEntitiesClosedAndreas Müller06/12/2020

Actions
Related to Edit - bug #9775: Open issues for web app media in the image galleryNewAndreas Kohlbecker09/20/2021

Actions
Related to Edit - feature request #8028: Better representation of web app media in the image galleryClosedAndreas Kohlbecker01/28/2019

Actions
Related to Edit - feature request #3630: Taxeditor should add mimetype of mediaRepresentations automaticallyNewKatja Luther07/30/2013

Actions
Copied to Edit - feature request #9547: Show warning in TaxEditor if a MediaRepresentation can not be shown in a ViewerNewKatja Luther03/24/2021

Actions
Actions #1

Updated by Andreas Müller over 1 year ago

  • % 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

Actions #2

Updated by Andreas Müller over 1 year ago

  • Status changed from New to In Progress
Actions #3

Updated by Andreas Kohlbecker over 1 year ago

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.

Actions #4

Updated by Andreas Müller over 1 year ago

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).

Actions #5

Updated by Andreas Müller over 1 year ago

  • Target version changed from CDM UML 5.15 to CDM UML 5.29
Actions #6

Updated by Andreas Müller 10 months ago

  • Related to feature request #9090: Implement external links for identifiable entities in TaxEditor added
Actions #7

Updated by Andreas Müller 10 months ago

Actions #8

Updated by Andreas Müller 10 months ago

  • Status changed from In Progress to Closed
  • Target version deleted (CDM UML 5.29)
  • % 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.

Actions #9

Updated by Andreas Müller 10 months ago

Actions #10

Updated by Andreas Müller 10 months ago

  • Copied to feature request #9547: Show warning in TaxEditor if a MediaRepresentation can not be shown in a Viewer added
Actions #11

Updated by Andreas Müller 10 months ago

  • Related to feature request #9548: Handle links to websites, webapps or similar in image galleries (simple and UV) added
Actions #12

Updated by Andreas Müller 10 months ago

Actions #13

Updated by Andreas Müller 4 months ago

  • Related to bug #9775: Open issues for web app media in the image gallery added
Actions #14

Updated by Andreas Müller 4 months ago

Actions #15

Updated by Andreas Müller 4 months ago

  • Related to feature request #3630: Taxeditor should add mimetype of mediaRepresentations automatically added
Actions

Also available in: Atom PDF