orderedAttachment (and orderedTag?)

[trwnh]

Please Indicate One:

• Editorial
• Question
• Feedback
• Blocking Issue
• Non-Blocking Issue

Please Describe the Issue:

pitch

problem: sometimes you want to have attachments in a certain order, but attachment is an unordered set by default

solution: define orderedAttachment similar to orderedItems

{
	"@context": [
		{
			"orderedAttachment": {
				"@id": "https://...",
				"@type": "@id",
				"@container": "@list"
			}
		},
		"https://www.w3.org/ns/activitystreams"
	]
}

i am unsure if orderedTag makes sense as tag is not used purely for "tags" in the categorization sense, but doubtless if tumblr or some tumblr-like implementation wanted to order their tags, they would have no way of doing so.

[evanp]

As with email, technically the attachments for an AS2 object are not ordered, but most clients seem to treat them as ordered. It might be a best practice to treat these objects as ordered, even if not well defined in the spec.

However, it may make sense to have a more precise definition of when attachments are specifically ordered and when they can be treated more loosely.

The current option, that works without a change to the AS2 context or an extension, is to use the "@list" technique mentioned JSON-LD:

{
   "@context": "https://www.w3.org/ns/activitystreams",
   "type": "Note",
   "content": "This is the content",
   "attachments": {
     "@list": [
          {
              "type": "Image",
              "name": "Image 1"
          },
          {
              "type": "Image",
              "name": "Image 2"
          } 
      ]
   }
}

The downside of this technique is that it's not (to be confirmed) widely used, so may confuse consumers of the document.

Adding an extension property that has "@type": "@list" as above would be more explicit and probably more backwards-compatible.

Creating this extension is probably a good FEP project.

[trwnh]

The current option you propose would add more complexity for "plain JSON" implementations that don't understand LD. These implementations have no way to signal to each other that attachments, tags, etc. are ordered. If orderedItems can exist, and it does exist for this very reason, then I think it is worth considering which other properties might be explicitly defined as ordered.

It feels very inelegant to say "just pretend they're ordered" without making them actually ordered. You may as well do a breaking change and redefine them in the context document to be @container: @list in that case... which would close the door on any AS2 producers that did indeed intend an unordered set. Having an orderedProperty variant is a much cleaner way of handling this. Well, either that or requiring LD, but the latter would also be a breaking change and a controversial one at that.

The one thing I do have to ask about, though: with FEPs, there is not a clear authority to propose terms within the activitystreams namespace. It would probably be a good idea to clearly establish the conditions and process for amending the context document to add or change terms. Otherwise, we might proceed with putting such orderedAttachment etc etc in an FEP-specific context. Not exactly a blocker, but the former would be preferred.

[evanp]

@trwnh see #540 for how this will get resolved. If this is a feature you want, you should start with a FEP. Can you get that going?

[trwnh]

https://codeberg.org/fediverse/fep/pulls/110/files

[trwnh]

it has come to my attention (mastodon/mastodon#25588 (comment)) that some implementations such as mastodon already author as2 documents where attachment and tag are forced to be arrays even when containing 1 or 0 values. given that implementations such as mastodon likewise assume these arrays to be ordered always, it seems like there is an argument to be made for not going with orderedTag and orderedAttachment, but instead changing the normative context to make these properties always ordered. caveat: as stated before, this closes the door on producers who wish to author explicitly unordered sets of attachments or tags.

[silverpill]

Are there any use cases where unordered set might be desirable?
Media attachments and key-value pairs in profiles are assumed to be ordered by many implementations (and users), so I'd support making attachment an ordered property.

[trwnh]

Unordered sets are often semantically more accurate, but that's about it, I think. It matters for RDF and RDF canonicalization but not much else off the top of my head.

[melvincarvalho]

It matters for RDF and RDF canonicalization but not much else off the top of my head

Hi @trwnh, this isn't mainly about RDF or canonicalization. It's about merging data from different sources, representing the web's data model.

This is an overhead to the web of data model, but it provides utility by contributing a relatively federated, interoperable, and decentralized aspect to the architecture - tho that is perhaps underused currently.

Should the fediverse interact with other web systems, merging various data becomes a cheaper operation with Linked Data. The end goal is a vast social graph spanning the web where a user's footprint is distributed across multiple domains without singular control.

[trwnh]

@melvincarvalho i meant using an ordered @list when in reality the order doesn't matter -- we are discussing the consequences of making a normative change to attachment and tag, versus defining a new orderedAttachment and orderedTag with the same @id but different @container (as is currently done for orderedItems being defined as as:items but with @container: @list)

basically: what are the consequences of saying that "order matters" when it actually doesn't? in several cases, it does matter; in other cases, it doesn't.

[trwnh]

Generally, this question extends to the following properties in popular practice:

• attachment (order of attachments sometimes matters)
• tag (order of tags can matter, e.g. tumblr)
• oneOf (order of poll options often matters)
• anyOf (order of poll options often matters)

Per SocialHub discussion, our options are, from least messy migration to most messy migration:

• 1: Manually override the term definition, per-document. This allows producers to opt into ordering for these properties, on a per-document basis. However, only LD-aware consumers will be able to tell the difference. (AS2 also forbids overriding AS2 terms, but consider this a willful violation.)

• 2: Make normative changes, for everyone. This changes the AS2 context to align more closely to what most producers are already doing or assuming, essentially opting into (1) for everyone. However, some old documents might no longer be valid, if they contain a single item rather than an array.

• 3: Use new orderedX properties. This removes the ambiguity completely, for both LD-aware and plain-JSON consumers; however, it requires plain-JSON consumers to check for the new orderedX properties, and this may result in producers duplicating information in both the unordered and ordered properties, which has unintended consequences for the LD representation.

For example, given the following:

{
  "@context": [
    "https://www.w3.org/ns/activitystreams",
    {
      "orderedAttachment": {
        "@id": "as:attachment",
        "@type": "@id",
        "@container": "@list"
       }
    }
  ],
  "orderedAttachment": ["one", "two"],
  "attachment": ["one", "two"]
}

It expands into the following:

[
  {
    "https://www.w3.org/ns/activitystreams#attachment": [
      {
        "@id": "one"
      },
      {
        "@id": "two"
      },
      {
        "@list": [
          {
            "@id": "one"
          },
          {
            "@id": "two"
          }
        ]
      }
    ]
  }
]

Compacting against only AS2 without the orderedAttachment extension results in this:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "attachment": [
    "one",
    "two",
    {
      "@list": [
        "one",
        "two"
      ]
    }
  ]
}

• 4: Redefine these properties as collections. This allows the use of ordereditems. However, existing implementations will almost certainly be confused by this change. In some ways, this is a harder break than (3), but with cleaner results. Funnily enough, no changes are needed to the normative context, only to convention (although AS2-Vocab examples could be reworked).

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "type": "Question",
  "name": "What is the answer?",
  "oneOf": {
    "type": "Collection",
    "orderedItems": [
      {
        "type": "Note",
        "name": "Option A"
      },
      {
        "type": "Note",
        "name": "Option B"
      }
    ]
  }
}

• 5: Using bits of semi-expanded LD within otherwise fully-compacted LD. Tangentially given option 3, we might say that instead of defining orderedX we can "simply" take the not-further-compactible @list notation and use it as-is.

Proposed solution: A single-item @set containing only a JSON-LD @list node, like so:

{
  "@context": "https://www.w3.org/ns/activitystreams",
  "attachment": {
    "@list": [
      "one",
      "two"
    ]
  }
}

Caveat as mentioned by Evan above: this is probably not expected, and it's a bit weird, but otherwise "technically valid".

One thing that might be worth exploring: Can we explicitly instead declare it to be an unordered set? I assume not, since @set is already the default) Indeed not, since @set compacts back to what we currently have, which is "assumed" to be ordered despite not actually being ordered.

[trwnh]

interestingly, another example comes to mind of when sometimes you do want unordered -- unordered poll options may be presented in random order, i.e. if the producer wishes them to be randomized (to reduce first-option bias)