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

@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?

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 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 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 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",
  "@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://tools.ietf.org/html/rfc4998> for the use of
>
> Merkle Trees for efficient time stamping (and long-term preservation of
> evidence
>
> as addressed in ETSI TS 119 512
> <https://www.etsi.org/deliver/etsi_ts/119500_119599/119512/01.01.01_60/ts_119512v010101p.pdf>,
> 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://tools.ietf.org/html/rfc3161> 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 proposal
>
>
>
> Hi folks,
>
>
>
> I'm one of the editors of a recent schema.org proposal for time-stamping
> content via blockchain
> <https://github.com/schemaorg/schemaorg/issues/2756> 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 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://w3c-ccg.github.io/security-vocab/> only to end up
> feeling completely overwhelmed by it and subsequently have come to a halt
> in working on our schema.org 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",
>   "@type":"Article",
>   "name":"A time-stamped article",
>   "mainEntityOfPage":"https://example.com/time-stamped-article/",
>   "timestamp":
>   {
>     "@type":"BlockchainTransaction",
>
> "identifier":"0fce9c929ef03838775703d4cf55b7b1bdd6a5cc3503a2606dbe3b6c0cf0a802",
>
> "hash":"8A258E516081C36B866812E49495628CBDC1DD4126DB321A28AE95EE55B83BAB",
>     "hashingKey":"
> https://example.com/json/?key=8A258E516081C36B866812E49495628CBDC1DD4126DB321A28AE95EE55B83BAB
> ",
>     "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",
>   "@type":"Key",
>   "dateCreated":"2020-09-27T20:28:41+01:00",
>   "isBasedOn":"https://example.com/time-stamped-article/",
>   "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>..."
> }
>