Re: Proposal: Structured Previews

Hi all.

I still think that the Reconciliation API could be expressed under JSON-LD.

I couldn't agree more with this and the rest of your reasoning Thad, and I
would be willing to both contribute to such an effort or outright sponsor
work on it, we have plenty of real world use cases. We actually already use
RDF for reconciliation service discovery and for extending the
specification. To be honest the only reason we haven't already done this
work ourselves for our own services is compatibility with the specification
and OpenRefine.org.

That said, the existing proposal for structured previews is not in conflict
with the idea of enabling JSON-LD throughout the specification and I would
consider it a different use case. I could see benefits beyond our own to
pursuing structured previews before moving the specification to JSON-LD as
the latter would benefit from being a breaking change(not only trying to
map the existing JSON with a context but also adopting standard properties
in place of existing ones). The efforts could then be merged very easily as
illustrated by your example at GitHub.

Albin

On Thu, Oct 31, 2024 at 3:43 AM Gregory Saumier-Finch <
gregory@culturecreates.com> wrote:

> Hi Thad,
>
> Jumping into this thread…
>
> I would also like to see a JSON-LD version of the Reconciliation API. I
> would be willing to assist with vocabs and the implementation of an actual
> reconciliation service responding with JSON-LD.
>
> Sounds like a good topic for the next monthly meeting.
>
> Regards,
> Gregory
>
> On Oct 30, 2024, at 9:40 PM, Thad Guidry <thadguidry@gmail.com> wrote:
>
> 
> Thanks Albin,
>
> I've commented in your PR on my preference for using JSON-LD to represent
> structured previews, instead of just JSON itself, as well as giving my
> rationale for that preference.  I'm also well connected to structured data
> on the web, and for years have been participating and tracking various
> standards now quite prevalent throughout GLAM and Science institutions
> sharing their Linked Data.  There's also alternative formats that the
> JSON-LD working group has been tracking and reviewing such as YAML-LD and
> others.
>
> I still think that the Reconciliation API could be expressed under
> JSON-LD.  I don't see a reason why we would limit clients to not also use
> JSON-LD for reconciliation.  We would simply need to just publish a new
> Reconciliation Vocab context for publishers to use.  Consuming the recon
> results would be a choice of original "recon" or "json-ld" formats
> depending on client preferences or services preferences.
>
> Drafting that new Reconciliation Vocab could be done by me, and others
> willing to lend a hand, and it wouldn't be that hard (days).  Then
> publishers would have an alternative query results standard and could add
> into their manifest that - "resultFormats": ["json-ld", "recon"] to tell
> consumers that query results could be returned alternatively as JSON-LD
> with the expectation that an "@context":"
> https://reconciliation-api.github.io/vocab/json-ld" is within the result.
>
> Deep thoughts?
>
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/
>
>