MSC3574: Marking up resources #3574
Conversation
Initial commit before PR
turt2live
changed the title
gleachkr
changed the title
turt2live
added
client-server
This approach fell away during drafting
There was a problem hiding this comment.
it would be nice if this msc gave some rationale for its design choices and threads section in the alternatives section.
maybe it's to early but generally this seems like a thing that would integrate with widgets, so perhaps that's something to consider when speccing.
proposals/3574-resource-markup.md
Outdated
| @@ -0,0 +1,157 @@ | |||
| # Marking up resources | |||
|
|
|||
| This MSC proposes a way to annotate and discuss various resources (web pages, documents, videos, and other files) using Matrix. The general idea is to use [Spaces (MSC1772)](https://github.com/matrix-org/matrix-doc/pull/1772) to represent a general resource to be annotated, and then a combination of child rooms and [Extensible Events (MSC1767)](https://github.com/matrix-org/matrix-doc/blob/matthew/msc1767/proposals/1767-extensible-events.md) to represent annotations and discussion. This MSC specifies: | |||
There was a problem hiding this comment.
you introduce the msc as relying on spaces, rooms (and formerly threads). if we read a bit further, we learn that a space will represent a "file" that is being discussed and seemingly rooms are the individual annotations. it is not clear to me how threads play into this?
to me it seems more obvious that an annotation would be represented by a thread start, and then the discussion of that annotation is the thread. what is your design intention with rooms instead?
this picture in my mind is a bit influenced by the idea of full screen widgets as we have seen them in twim and matrix live. the pdf and website annotation apps are specialized matrix clients. in my minds eye I see a mashup of these ideas. the annotations could be backwards compatible by loading "the file" in a widget and then compatibility of your markup spec with regular clients like element allows people to discuss using the regular ui.
There was a problem hiding this comment.
Thanks! I've mentioned the widget idea, and discussed the rationale for not focusing on threads.
* add discussions as threads alternative * note possibility of a widget interface
Initial commit before PR
This approach fell away during drafting
* add discussions as threads alternative * note possibility of a widget interface
w3c spec duplicates some Matrix functionality
|
|
||
| 1. In practice, near-term prospects for interoperability might be limited. There are not many [implementations](https://w3c.github.io/test-results/annotation-model/all.html) in the wild. Even, for example, Hypothes.is supports only part of the w3c data model, and [apparently only in an undocumented read-only capacity](https://github.com/hypothesis/h/blob/28c2c5bdf5d85f12307ed56f90995ad1c1f214ac/h/routes.py#L122). If desired, bridging might be better accomplished by using APIs for individual annotation services directly, together with the minimal serialization proposed above, rather than by routing through an incompletely supported data model. | ||
| 2. The w3c spec's selectors for PDF annotation are somewhat limited, and more generally the set of selectors built into the spec are not likely to cover all use cases. The w3c spec does incorporate [an extension mechanism](https://www.w3.org/TR/annotation-vocab/#extensions), via JSON-LD contexts. Perhaps the matrix spec for document markup would want to eventually incorporate a well-documented JSON-LD context for any extended selector types that become important. | ||
| 3. The w3c spec is sufficiently expansive that it overlaps to some extent with existing Matrix functionality. For example, you could have an annotation targeting a matrix event, whose "purpose" (a field allowed by the w3c spec) is "reply" (a value listed in the spec). Care would need to be taken not to create confusing duplications like this. |
There was a problem hiding this comment.
Taking a step in the other direction, we could consider having a reply to an annotation as annotation.
I.e., given we already introduce a Room for annos about a Resource, why not go a step further and say an Anno is yet another Resource you can anno.
We'd need a URI in order to refer, eh! Luckily an event is uniquely identifiable by it's hash.
Which can be represented as a Hash URI.
E.g., hash://sha256/bafy...AliceAnno1
Not sure whether Web Annotation support JSON Pointer as Selector. Given it does, we can point to a specific bit of annotation user's interested in, likely it's text.
E.g., hash://sha256/bafy...AliceAnno1#/content/body
And bolt on range selector atop if user wants to reply to a particular bit of it. Akin to Rich Reply.
Whether this uniformality is a path to madness is an open question.:)
As a side note, Zettlekasten method is popular for knowledge engineering. Curious whether it could be modeled with Web Anno. Anyways, interesting idea, kuddos for thinking on it!
Rendered
Signed-off-by: Graham Leach-Krouse gleachkr@gmail.com
Implementation: