@bonfire A bit, yeah. I'm sure each one has pros and cons for the purpose, but I'm in favor of picking something that's ready for use with linked data. We might be able to avoid defining a new JSON-LD context that way.

schema.org's CreativeWork is a supertype of ScholarlyArticle. Curious why ORCID doesn't use the subtypes even though they have the type information in their own data. (Their JSON schema is altogether different from their JSON-LD I think.)

@mayel @jonny @smallcircles

@julian @bonfire @mayel @jonny

With #OpenScience we talk of an entire field that has a lot to fight for, given all that's wrong around academic publishing processes and the strangehold of commercial parties.

Also a field full of people who might design/deliver rock-solid robust & *interoperable* open standard specifications.

There's ample opportunity to start something like ForgeFed, a dedicated protocol extension spec. Working name: #ScienceFed and it can be homed at https://codeberg.org/fediverse

@trwnh Thanks, I hadn't come across this. Nice and detailed. I like that this can encode the type of citation (discusses, summarizes, critiques, ...), I don't love that it does it with a long list of optional properties on the citation object rather than one property with a value range. Feels like it'd be a pain to parse for plain JSON consumers this way. Will think on it more.

@bonfire @mayel @jonny @smallcircles

@julian @bonfire @mayel @jonny @smallcircles

you can reify the citation as a Citation object and then express the type of citation with the hasCitationCharacterization property? see the explainer's first example on "direct form" vs "reified form"

@julian

makes sense, though would be great to heard from academics on this, whether involved/informed on the the topic of schemas or not...

and thanks for the hint, will have to check if we're getting the regular json version instead of the json-ld one...

@mayel @jonny @smallcircles

Obligatory reference when looking at standards

@julian @mayel @jonny @smallcircles

@bonfire @julian @mayel @jonny

The situation that exists now is that each dev creates their own standard, which is way way worse.

@bonfire @julian @mayel @jonny

Also btw, this discussion takes place on an ephemeral channel, where after the toot flood everyone goes their own way with different expectations

@bonfire @julian @mayel @jonny

At least I will state my interest from the perspective of custodian of Social coding commons movement, which has an ambition that open science becomes seamlessly embedded within the commons with lowest barriers to free knowledge transfer towards broader society and back.

The chaordic organization formula that I am pondering allows for pillars to be created around specific themes, to help make them strategically and organically grow over time. Like Open Science.

@bonfire Right – with OSN you're also thinking about academic creation, not only sharing? So letting authors declaratively cite specific sources in their posts could be good, as would searching/filtering for “what else cites this”.

Although tbh, my motivation for now is interop between Encyclia and OSN. I want Bonfire to recognize Encyclia posts as what they are (automated metadata summaries of specific academic works) and separate those from human discussions.

@mayel @jonny @smallcircles

@bonfire @julian @mayel @jonny

Oh, I should also mention that I intend to port and reboot https://fedi.foundation which I can also offer as a place where ScienceFed can inform the public about its work.

This site is intended to be a multi-author publishing service for participants in Social coding commons, specifically around themes of applied research for the social web of tomorrow.

@smallcircles @julian @mayel @jonny does it federate?

@bonfire FWIW, Encyclia currently fetches plain JSON from ORCID and re-emits as human-readable ActivityPub Notes. ORCID's own types, which are used in (non-LD) JSON payloads, are listed in the second column here: https://info.orcid.org/ufaqs/what-work-types-does-orcid-support/ Dunno if those map cleanly to schema.org types but the palettes are small enough that we can figure it out.

@mayel @jonny @smallcircles

@julian
@bonfire @mayel @smallcircles
I have only been loosely following but I am a "spec on the table" kinda gal. Draft spec and implementation first, then bikeshedding later.

@julian

That should be easy enough to get working as-is to begin with, and we can then progressively enhance with schemas?

@mayel @jonny @smallcircles

@smallcircles @julian @bonfire @mayel @jonny

for illustrative examples, see https://linkedresearch.org/calls#contributions-and-review and https://csarven.ca/linked-data-notifications

go ahead, inspect the html, try to fetch it as json-ld, the works

@trwnh
@smallcircles @julian @bonfire @mayel
Ya ya. Adding LD to documents is easy. Making use of it at scale is hard.

@jonny @smallcircles @julian @bonfire @mayel i am finding that the challenge isn't so much "making use of it as scale" as it is specifically "being understood at scale". it's a problem that we have even with natural language. you have the capability to make use of information that you understand, but it's the understanding that's the hard part. and also discovering that information in the first place, and being able to find it when you need it. compared to that, use cases are straightforward.

@trwnh
@smallcircles @julian @bonfire @mayel
I think basically we are saying the same thing because understanding is a prerequisite to use for me so yes, agreed.

@trwnh
As a side note, I think RDFa is a great idea, I tried to use it in a document and make a markdown preprocessor to be able to use it with semantic mediawiki-style wikilinks [[predicate::object|display text]] where the document is the implicit subject, or [[subject::predicate::object]] and have those render out as a elements with RDFa. But then I learned that rdflib had dropped support and there weren't any actively developed parsers, so I gave up because I wasn't gonna write one and what's the point in writing something that can't be parsed easily.