Project

General

Profile

feature request #9067

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

Added by Andreas Müller 10 months ago. Updated 27 days ago.

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

100%

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 TaxEditor New 06/23/2020
Related to Edit - feature request #9545: Remove "External Link type" completely Closed 03/24/2021
Related to Edit - feature request #9546: [DISCUSS] Merge ExternalLink and MediaRepresentation New 03/24/2021
Related to Edit - feature request #9548: Handle links to websites or similar explicitly in image galleries New 03/24/2021
Related to Edit - feature request #9064: Add ExternalLinks to IdentifiableEntities Closed 06/12/2020
Copied to Edit - feature request #9547: Show warning in TaxEditor if a MediaRepresentation can not be shown in a Viewer New 03/24/2021

Associated revisions

Revision 56a54a09 (diff)
Added by Andreas Müller 10 months ago

ref #9067 preliminary added link attribute to Media to support solutions 3 and 4 if required

History

#1 Updated by Andreas Müller 10 months 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

#2 Updated by Andreas Müller 10 months ago

  • Status changed from New to In Progress

#3 Updated by Andreas Kohlbecker 10 months 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.

#4 Updated by Andreas Müller 10 months 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).

#5 Updated by Andreas Müller 10 months ago

  • Target version changed from CDM UML 5.15 to CDM UML 5.22

#6 Updated by Andreas Müller about 1 month ago

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

#7 Updated by Andreas Müller 27 days ago

#8 Updated by Andreas Müller 27 days ago

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

#9 Updated by Andreas Müller 27 days ago

#10 Updated by Andreas Müller 27 days ago

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

#11 Updated by Andreas Müller 27 days ago

  • Related to feature request #9548: Handle links to websites or similar explicitly in image galleries added

#12 Updated by Andreas Müller 27 days ago

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 40 MB)