Meeting with editors and their questions

Software redaktor.me
1

Today we had a meeting at Gruner & Jahr where various magazine editors, picture editors and tv people tested some UI for redaktor which will become partly OpenSource [initially within http://github.com/redaktor/widgets-preview
This was very insightful, about the posting interface the main takeout was what they want to see initially (like the main fields nameMap, summaryMap, contentMap and attaching types and media) and that it needs two “advanced” steps more, their vocabularies and for some cases e.g. schema.org and so I showed approaches like http://skohub.io cause the editor (e.g. right sidebar is fine) …

Then we discussed the reading part (the ActivityPub/LD-widgets) and →
While it was all just about visual representations, 3 questions / feature requests emerged which are more at the vocabulary level:

• Headlines
We discussed the different approaches. redaktor has a markdown parser, so of course it would be possible to write the headlines in the summary.
There are many cons, show stoppers are that the editors want to search them and in some cases like sport event live they are generated automatically. Apart from that the visual styling should be consistent and handled by the theme designed by designers rather than the taste of texters …

In fact, we would need 3 properties cause a typical “headline” consists at least of ‘kicker’, ‘headline’, ‘byline’
The kicker is usually a topic, catchy word or location, often color-accented while the byline is often additional context about the format or contributors but can also be anything.

BBC, all 3 elements

Bildschirmfoto 2021-09-23 um 22.47.30
Bildschirmfoto 2021-09-23 um 22.47.301166×408 41.3 KB

Guardian, 2 elements + summary

Bildschirmfoto 2021-09-23 um 22.51.50
Bildschirmfoto 2021-09-23 um 22.51.50504×580 50.1 KB

We can use schema but in ActivityPub, we use the nameMap or name property to collect them.
“A simple, human-readable, plain-text name for the object. ” (?)

Our resolution is 0 = headline, 1 = kicker, 2 = byline
{"name": ["UK Haiti envoy …", "US & Canada", "Daniel Foote says …"]}

Better suggestions?

• Dates, Locations and Persons
belonging to the content of CreativeWork in an object rather than to the object itself

The problem, how to describe it e.g. for an image.
For Dates, there is published, updated, deleted but people want something like contentCreated.
For them it is equally important if e.g. a picture showing an embassy is from 1975 or 2021 …

For Locations, we have location where multiple locations related would be specified but we can’t specify the contentLocation. With schema contentLocation or Dublin Core it must be a property of the root, so we simply use all properties.

• Map improvements

A feature request was to show boundaries / polygons or geospatial infos like evacuation zones and I found How to represent Places in an event - so, what is the preferred way to specify a polygon instead radius?

2

Headlines

This works, but you give up the semantics and concepts of the domain you are modelling entirely, just to cram the information into the existing specs. I guess the reason for doing so is that you want other fedi apps to also still be able to do something with the data.

On the whole I feel it is time that we start to investigate and venture into having real domain-specific AP extensions. And in this case it means maybe not being afraid to define your vocab for News Media or Journalism or whatever domain. And then maybe pass a markdown doc in one of the existing properties of the spec that other apps can fall back to if they don’t support that.

1 Like
3

Well, maybe a misunderstanding, of course the JSON-LD on the pages will contain anything in the semantics and concepts of a domain.
@pukkamustard described it in Structured Data for google: Murmurations protocol for directories and maps - #3 by pukkamustard

And in case of public content we use it with the full context of all our known vocabularies.

btw: I have created a minimized version of the schema.org LD context for ActivityPub clients: widgets-preview/index.ts at f8f96fb97cd8b7ccc2dabfcafc57d8c0c59967e5 · redaktor/widgets-preview · GitHub
This expands to the bare context with children which can be used for Miller-Columns or Trees in posting interfaces, demo https://codepen.io/sebilasse/full/NWgOeXV …

So, for redaktor anything is fine.
The headlines example will have the first (or only) headline as the main one …

It is just that I do not consider the fact that any Creative Work has at least 2 different locations
“Where was the image taken?” Earth, e.g. latitude longitude
“What does the image show?” Moon
[or think of paintings]

So, it is exactly right that we can specify multiple locations in ActivityPub but what I would do to express is (see @context)

location: [
  {type: ['Place', 'schema:contentLocation'], ...},
  {type: ['Place', 'http://example.com/whateverThisIs']}
]

But this works only per schema @type and not per property.
So usually this works but in this case the property contentLocation must be an array of Place at the same level than location in ActivityPub …

So, I guess, it is better to explicitly specify it in the LD context and other implementations will ignore it (if they do not consume vocabulary foo [here schema…]) –

On the other hand: Is it more domain specific than e.g as:sensitive which mastodon specified as extension?
The spec. clearly says

consuming implementations that support the Place object must support the use of these properties.

And that does not make sense in terms of any creative work if we do not know which Place is meant … So, it would be an easy extension like …

location: [
  {type: ['Place', 'as:ContentLocation'], ...},
  {type: ['Place', 'as:LocationCreated']}
]

The underlying problem is that I can specify locations per Activity and per Object.
So, if I would have an additional Activity, which is ContentCreated anything here would be fine anyway but Created is

Indicates that the actor has created the object .

And that usually happens at a third location, at home at my computer …

1 Like
4

Well, I would agree to that.
I really tried to follow the discussion about mastodon markdown support.
Correct, me if I am wrong,

Issues before had been closed and the first relevant was markdown support in toots · Issue #761 · mastodon/mastodon · GitHub which went to Text formatting · Issue #853 · mastodon/mastodon · GitHub and then to Add emphasis and code span syntax by Gargron · Pull Request #10787 · mastodon/mastodon · GitHub where they said e.g. “yeah I think page structure is a good reason to exclude headings, although maybe we could support <big> :P” …

1 Like
5

Nice. Thanks for the elaboration. FYI, I think I passed the link to this multi-part blog post before, but this may be interesting to you:

1 Like
6

Oh yes, that is a very nice article.
Using schema-dts and for now just extending the ActivityPub Classes with most useful values.