example 79 is invalid because is uses 'width', 'height' property on Image (they are only defined as in Domain of Link)

[gobengo]

Please Indicate One:

• [x] Editorial
• [ ] Question
• [ ] Feedback
• [ ] Blocking Issue
• [ ] Non-Blocking Issue

Please Describe the Issue:

• via https://github.com/gobengo/activitystreams2-spec-scraped/issues/15
• the vocabulary sepc defines 'width' and 'height' properties as having a Domain of Link
• but ex 79 and 80 use these properties on an Object type ('Image'), which is not in the domain of these properties

recommendations:

• definitely: fix example 79 and 80 to either not use width/height on Image, or else to have the Image.url value be a Link, and put the height/width on there
• maybe: consider expanding the domain of 'width', 'height' to include Image. While this may be tempting... I don't think it's strictly necessary. It's nice to be able to describe an Image that might have multiple URLs to embed with different sizes, e.g. to render the Image + many Links into a

[sebilasse]

IMO they should be valid for both. There are many many reasons and the main one is that we have responsive images and a srcset needing it anyway. I think it would be nice if ActivityPub would at least support HTML elements like picture … Also sharing another article https://www.smashingmagazine.com/2020/03/setting-height-width-images-important-again/

And just btw: The different issues mention some other wrong examples, maybe we can collect them, e.g. https://github.com/w3c/activitystreams/issues/496

[gobengo]

Noting that at least one implementation uses width and height on Document (not only is that not a Link, it's not an Image either)

bengo@bengo ~ ⚡  curl 'https://mastodon.social/@[email protected]/110818947889431675' -H "Accept: application/ld+json"  -L | jq '.attachment[0]'
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   127  100   127    0     0    520      0 --:--:-- --:--:-- --:--:--   535
100  5113    0  5113    0     0   6564      0 --:--:-- --:--:-- --:--:-- 15636
{
  "type": "Document",
  "mediaType": "image/png",
  "url": "https://social.network.europa.eu/system/media_attachments/files/110/818/909/103/538/953/original/82f3862c629f0275.png",
  "name": "7 challenges to help us change the course of the future!\n- Develop a website’s comment moderator\n- Develop a Gender-based violence Case builder\n- Develop a Deepfake detector\n- Develop a Collaborative walking-safety map\n- Develop an Awareness builder \n- Develop a Protection provider \n- Develop an Online Safety map \n\nRegister now - June 27 - September 15\n",
  "blurhash": "UNR34o.mI=m*CTz-IU%#vL%$S4nNcGwbn%Nd",
  "focalPoint": [
    0,
    0
  ],
  "width": 1600,
  "height": 900
}

[evanp]

We already have an erratum that says example 80 is technically incorrect and recommends using a Link.

We have several other remediations we can take:

1. Update the errata to note that example 79 has an identical problem with example 80.

2. A Erratum that says that the domain of width and height were intended to also extend to an Object or something more specific like Image or Video. It's been pointed out that in the wild this is largely assumed to be the case already.

3. An extension or other documentation that defines how and when to apply width and height to Image, Video, or other types.

[evanp]

I'm writing my book, and it sets my teeth on edge to say that you can put a width/height value on a Link but not an Image or a Video. We need to fix this in the next version, since it sucks.

Right now, the best option I can think of for this is using schema.org terms for width and height:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {"so": "https://schema.org/"}
  ],
  "type": ["Image", "so:ImageObject"],
  "url": "http://example.com/image.jpg",
  "so:width": "1024px",
  "so:height": "768px"
}

[gobengo]

but not an Image or a Video

@evanp et al, which normative language in the text do you see as prohibiting this?

I don't see it rfc2119-prohibited anywhere in the spec text, nor do I see any rfc2119-requirements about how it can be used.

While I filed this issue as an editorial one curiosity, I no longer find it too pressing since I've been doing more requirements parsing/tesitng. A reading of the testable statements in the activity-vocabulary doesn't seem to prohibit using it as in the example above. I encourage people to use whatever properties they want wherever they want and only be constrained by explicit requirements/prohibitions in the spec.

We need to fix this in the next version, since it sucks.

A new version is not the only way of decreasing the suck, and feels a bit heavy handed here. As with all errata, this can be remedied by a candidate correction to include Image (or Object) alongside Link in the informative descriptions of the domains of width and height to avoid the confusion. As part of the required 'wide review' of such resolutions, I would be happy support such a proposal.

Right now, the best option I can think of for this is using the Dublin Core terms for width and height:

This is a requirement in activitystreams-vocabulary: "However, to avoid possible interoperability issues, implementations MUST avoid using extension types or properties that unduly overlap with or duplicate the extended vocabulary defined here."

imo just use width height from as2 in as2 docs and on any resource it adds value to. It's unlikely anything breaks due to having it on non-Link-typed objects (as evidenced by Mastodon using it on Documents and things working fine).

[csarven]

@evanp , regarding your DC Terms width/height use, AFAICT those properties do not exist. Did I misinterpret what you're saying or did you mean something else?

[evanp]

@gobengo the Domain of width and height is Link only.

[evanp]

@csarven you're correct; dcterms doesn't have width and height. I changed it to Schema.org.

[evanp]

@gobengo I re-opened the issue since I think it's not resolved yet. If it's important to you that your name not be on it, I'll start another issue.