Re: looking for help with/guidance for a schema.org proposal

Blockchain practices complement some SDOs, particularly where one needs to
pay for a commodity service. Timestamping looks like the ultimate cloud
commodity with a natural fit for the competing L2 aggregators. I imagine
that currently each timestamp service has a proprietary API even if they
all share the same Bitcoin or Ethereum anchor chains. RFC 3161 might be
just the thing to make these services substitutable and ubiquitous.

On Fri, Nov 6, 2020 at 12:47 PM Leonard Rosenthol <lrosenth@adobe.com>
wrote:

> Adrian – I think the short answer is: RFC 3161 is an open international
> standard from a recognized SDO (Standards Definition Organization) and the
> others are not.
>
>
>
> Leonard
>
>
>
> *From: *Adrian Gropper <agropper@healthurl.com>
> *Date: *Friday, November 6, 2020 at 11:45 AM
> *To: *Jarno van Driel <jarnovandriel@gmail.com>
> *Cc: *Leonard Rosenthol <lrosenth@adobe.com>, "public-credentials@w3.org"
> <public-credentials@w3.org>
> *Subject: *Re: looking for help with/guidance for a schema.org proposal
>
>
>
> What’s the relationship between RFC3161 and OpenTimestamps or other
> blockchain timestamp schemes ;-) ?
>
>
>
> On Fri, Nov 6, 2020 at 10:44 AM Jarno van Driel <jarnovandriel@gmail.com>
> wrote:
>
> "Yes, and that is, IMO, its biggest fail..."
>
>
>
> I'm sorry you feel this way about it. Personally I think it's very useful
> as an intermediate between publishers, more formal environments and
> consumers of such data. Having schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206783327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=22w8glrWWlfQf3uQxwoo26SIhuhnZQpVvKU7ppcrNaA%3D&reserved=0>
> be the one true center of all would IMO be presumptuous to say the least
> while also trampling on work done by others. Clearly there's always going
> to be some unfortunate overlap, though a lot of issues for consuming
> parties that come from this often (not always of course) can be resolved
> through some mapping of terms. At the same time I also feel it plays a very
> nice role in getting publishers (like myself) familiar with structured data
> and the fact there actually exist other (more formal) methods of annotating
> data (which, for example, in many cases I'd never have known existed).
>
>
>
> Anyways, each person clearly has the right have his own opinion about it,
> nevertheless I think it's of the utmost importance that what schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206783327%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=22w8glrWWlfQf3uQxwoo26SIhuhnZQpVvKU7ppcrNaA%3D&reserved=0>
> tries to accomplish doesn't get in the way of more formal/expressive
> standards, hence reaching out to people in this group to try to prevent our
> proposal does exactly that.
>
>
>
> Thanks for the additional comments and I'll definitely look into RFC 3161
> timestamps and AdES-based signatures as well (seems I got plenty of
> rabbit holes to dive into).
>
>
>
> Op vr 6 nov. 2020 om 15:39 schreef Leonard Rosenthol <lrosenth@adobe.com>:
>
> The ISCC is just a (potentially long) string – so you can store it in your
> JSON any way that you would like.
>
>
>
> > Schema.org is a vocabulary with as few constraints as possible
>
> >
>
> Yes, and that is, IMO, its biggest fail.  The lack of actual Schemas –
> made even more ludicrous by its name – makes its use in formal metadata
> environment difficult.   In the case of CAI, we did two things.  (1) We
> defined formal (JSON) schemas for some key schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206793314%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6hDkwqC%2FT3mF8IJZMBluaevtPa0he2o03wyDcwHmg5w%3D&reserved=0>
>  grammars such as `Place`, `GeoCoordinates` and `ClaimReview` and then (2)
> we enabled support for using any arbitrary Schema.org grammar.
>
>
>
> For timestamping, CAI uses standard RFC 3161 timestamps.  Not only it is a
> well understand and deployed solution, but it also aligns with our standard
> AdES-based signatures for compliance with ISO and ETSI standards and the
> legal requirements of the EU, Japan and other countries.
>
>
>
> Leonard
>
>
>
> *From: *Jarno van Driel <jarnovandriel@gmail.com>
> *Date: *Friday, November 6, 2020 at 8:20 AM
> *To: *"public-credentials@w3.org" <public-credentials@w3.org>
> *Cc: *"public-credentials@w3.org" <public-credentials@w3.org>
> *Subject: *Re: looking for help with/guidance for a schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206793314%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6hDkwqC%2FT3mF8IJZMBluaevtPa0he2o03wyDcwHmg5w%3D&reserved=0>
> proposal
> *Resent-From: *<public-credentials@w3.org>
> *Resent-Date: *Friday, November 6, 2020 at 8:18 AM
>
>
>
> @Leonard and @Tzviya, are there any resources that show examples of ISCC
> metadata in JSON so I can compare these with the different examples
> we created for our proposal?
>
>
>
> @Leonard, happen to have a resource showing examples of how the CAI aligns
> with schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206803310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HgNy3%2BDHqOowpmvuEGWYdyIVU0ff8vcAn6PxVKhgY%2Fg%3D&reserved=0>
> ?
>
>
>
> Schema.org is a vocabulary with as few constraints as possible so that
> publishers are free to describe the things they want. It's up to each
> individual consumer of schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206803310%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=HgNy3%2BDHqOowpmvuEGWYdyIVU0ff8vcAn6PxVKhgY%2Fg%3D&reserved=0> annotated
> markup (e.g. search engines, social media platforms) to decide for
> themselves which elements of the vocabulary they need/support for their
> applications, as well as for describing any constraints in regards to the
> data shapes and values they want from publishers.
>
>
>
> And so the intent behind our schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206813303%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nQBOvySxdTdgyvGkXVii4dnpyyMPC9E%2FYqUTQLPgGMc%3D&reserved=0> proposal
> is to be agnostic in regards to the identifiers (or any other value) that
> can be used/expressed (and any infrastructure/service used to generate
> these). Thus we're trying to come up with a schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206823295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rjSSWc%2BlSIWl4mapss3RCMXlrOFYHKJwmQkSrZ4XMk0%3D&reserved=0> method
> for describing timestamps (and the elements needed for these) that doesn't
> conflict with any major draft/proposal/standard out there yet has enough
> expressivity to 'point the way' to validators to be able to get the info
> they need (possibly elsewhere) and do their thing via their preferred
> methods.
>
>
>
> Practically this means that ids for DID, BLINK, ISCC and others - even
> though not incorporated in the examples I provided - could be expressed as
> an URN via JSON-LD's @id (or at least, that's how we think about it), e.g.
>
> {
>
>   "@context":"https://schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402779206823295%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=VUP9yjDDen6eGhFHbCDSa7s2j5Q42zqRQlObydxuEPQ%3D&reserved=0>
> ",
>
>   "@type":"BlockchainTransaction",
>
>
> "@id":"blink:ethereum:ropsten:0xafdcf0708ab37df3eef706ea0c1b985a8fa10b11607fe1c0558022b51f450635"
>
> }
>
>
>
> Which is why I'd love to have the examples I asked for (if there are any)
> so I can try to find out if our proposal contains anything that might cause
> any conflict (and possibly ask help if I fail in doing so myself).
>
>
>
> @Detlef, I'll take a look at the resources you provided. Thanks for
> pointing out long-term-preservation as well. To be honest it's not
> something we had discussed yet though it's something I'll definitely
> discuss with the others (we've taken the baby-steps approach to prevent our
> proposal being too granular from the start).
>
>
>
> Op do 5 nov. 2020 om 15:25 schreef <detlef.huehnlein@ecsec.de>:
>
> Dear Jarno,
>
>
>
> I would like to encourage you to look at RFC 4998
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc4998&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206833290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6GgIydJ6iXkfcEHm6erc%2BgIsE1PP9j1XFk9MnEuqaAI%3D&reserved=0>
> for the use of
>
> Merkle Trees for efficient time stamping (and long-term preservation of
> evidence
>
> as addressed in ETSI TS 119 512
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.etsi.org%2Fdeliver%2Fetsi_ts%2F119500_119599%2F119512%2F01.01.01_60%2Fts_119512v010101p.pdf&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206833290%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=esDhmqMHfopBEMeN%2B5qxmH6a9artcgPK0n6iqnOQYuQ%3D&reserved=0>,
> if the long-term perspective is important in your use cases).
>
>
>
> Maybe we could one day come up with a MerkleProof202x, which can be used
> with both
>
> blockchain based and classical RFC 3161
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc3161&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206843285%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tzH6N6T7KoHJZYiwZCnlUMK0XiauKgeKgTiZCnRzsKU%3D&reserved=0>
> time stamps?
>
>
>
> BR,
>
> Detlef
>
>
>
> *Von:* Jarno van Driel <jarnovandriel@gmail.com>
> *Gesendet:* Donnerstag, 5. November 2020 14:06
> *An:* public-credentials@w3.org
> *Betreff:* looking for help with/guidance for a schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206853283%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BcK1YDr0qAC572PeMvNtFOI9LObpcKabGBl184b1yuk%3D&reserved=0>
> proposal
>
>
>
> Hi folks,
>
>
>
> I'm one of the editors of a recent schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206853283%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BcK1YDr0qAC572PeMvNtFOI9LObpcKabGBl184b1yuk%3D&reserved=0>
> proposal for time-stamping content via blockchain
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fschemaorg%2Fschemaorg%2Fissues%2F2756&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206863273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3aj9s1%2FzITc6AHIC38xtCgBhO6IbKe69iXQFgRtRJ6k%3D&reserved=0> and
> am hoping you can provide us (the authors of the proposal) with some
> help/guidance as to how this proposal might be realized such that it:
>
>    - allows everyday publishers to publish markup to:
>
>
>    - timestamp their content in a 'simple' yet verifiable manner
>       - optionally provide the content used (a Key) for generating a
>       transaction hash
>       - optionally provide the content used for generating a transaction
>       hash of previous editions of the content (via a Key that refers to its
>       previous edition)
>
>
>    - *doesn't conflict *with the (enormous) amount of work this group has
>    already done
>
> Prior to posting the schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206873266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=MDMai%2FeyKmEYktQGZO1qQN2TXI6gm7l%2FTwdhRrWBSro%3D&reserved=0>
> proposal Manu Sporny was so kind to provide us with some resources that he
> recommended we should read (about merkle-proof, opentimestamps, chainpoint
> and hash-links) though after we posted the proposal it became clear we
> hadn't succeeded in preventing conflicts with MerkleProof2019 (and possibly
> also with other parts of the work this group has done).
>
>
>
> So over the last 4-5 days I've taken a real deep dive into the Security
> Vocabulary
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fw3c-ccg.github.io%2Fsecurity-vocab%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206873266%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=U%2F%2F6iSY4GtEBXaHFTD7SBN6fBsIEQuGwT%2FQ7M4IOUPI%3D&reserved=0> only
> to end up feeling completely overwhelmed by it and subsequently have come
> to a halt in working on our schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206883261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ThtXMXxu7NZ%2B7Jc6bRXcP0EyE7KELmCF7U1YgMHxDuI%3D&reserved=0>
> proposal as I realized we won't be able to get this done without your input
> (because we're set on not getting into conflict with your drafts).
>
>
>
> The (maybe naive) objective of our proposal is to provide publishers with
> an 'easy' solution to achieve the objectives I mentioned above and as such
> provide validators with the minimum data they need (entry-points so to say)
> to be to validate the timestamps (by getting the rest of the information
> they need elsewhere).
>
>
>
> Any help would be greatly appreciated!
>
>
>
> --
>
>
>
> The markup model for time-stamping content we've come up with thus far
> looks like this:
>
> {
>   "@context":"https://schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402779206883261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rJdiPgUhAgLWAqz%2BX0ykHk3%2FP44LRMILiNK6cCjfQAo%3D&reserved=0>
> ",
>   "@type":"Article",
>   "name":"A time-stamped article",
>   "mainEntityOfPage":"https://example.com/time-stamped-article/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Ftime-stamped-article%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206893259%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E%2BvE46Q1nG3AJwQkKJPvdd4F%2B9ie3GK6wrRUV0g4oyo%3D&reserved=0>
> ",
>   "timestamp":
>   {
>     "@type":"BlockchainTransaction",
>
> "identifier":"0fce9c929ef03838775703d4cf55b7b1bdd6a5cc3503a2606dbe3b6c0cf0a802",
>
> "hash":"8A258E516081C36B866812E49495628CBDC1DD4126DB321A28AE95EE55B83BAB",
>     "hashingKey":"
> https://example.com/json/?key=8A258E516081C36B866812E49495628CBDC1DD4126DB321A28AE95EE55B83BAB
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Fjson%2F%3Fkey%3D8A258E516081C36B866812E49495628CBDC1DD4126DB321A28AE95EE55B83BAB&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206903258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=6jdliZN1ryvVLDw8xA38vym68VUrlFf9rn%2FbJPaMeeI%3D&reserved=0>
> ",
>     "isPartOf":
>     {
>       "@type":"BlockchainBlock",
>
> "identifier":"058ca16036c058217753b01200118f3ed92bfb2cee9a6c75bdb7bb1d110a767e",
>       "blockHeight":3456789
>     },
>     "recordedIn":
>     {
>       "@type":"Blockchain",
>       "name":"eos",
>       "network":"mainnet",
>
> "identifier":"aca376f206b8fc25a6ed44dbdc66547c36c6c33e3a119ffbeaef943642f0e906"
>     }
>   }
> }
>
>
>
> The markup model for the Key looks like this:
>
> {
>   "@context":"https://schema.org
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fschema.org%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402779206903258%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=QJNQTfF9F9m9EhdFeYUMEt1W4LbHpMPG8dEX69%2FcuCQ%3D&reserved=0>
> ",
>   "@type":"Key",
>   "dateCreated":"2020-09-27T20:28:41+01:00",
>   "isBasedOn":"https://example.com/time-stamped-article/
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2Ftime-stamped-article%2F&data=04%7C01%7Clrosenth%40adobe.com%7C9cdfa68459824e75100b08d882735511%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402779206913250%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=9SFILp%2FNGa8FWR0cLHKNKGcLR2yHwamDZoKFK%2F88K38%3D&reserved=0>
> ",
>   "encodingAlgorithm":"SHA-256",
>   "encodingFormat":"text/html"
>   "text":"<h1>Nunc eget lorem dolor sed</h1>\t\t\n\t\t\t<h2>Suspendisse
> sed nisi lacus sed viverra tellus.</h2>\t\t\n\t\t\t<p>Non consectetur a
> erat nam at lectus urna. Ut porttitor leo a diam sollicitudin tempor id
> eu.</p>..."
> }
>
>