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 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
> 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  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 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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656092991697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ci5AYsHapNcLbrqL4ZHmTHiVBSBoC%2FUp7ij%2FOHiMAOU%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656092991697%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Ci5AYsHapNcLbrqL4ZHmTHiVBSBoC%2FUp7ij%2FOHiMAOU%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093001690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dceLN6%2FQnyC54BvgbNQzvZ4mwqnqRIoSmcXZbtO8SRU%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093001690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=dceLN6%2FQnyC54BvgbNQzvZ4mwqnqRIoSmcXZbtO8SRU%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402656093011686%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hcUwoUx4SLBEqbkvIN%2BpjnvJbehh%2BUxlr5IVJa51Zk0%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093011686%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=O9C4tvxDHu8CwUu2f7J03Oe6rdiZfkuPceeMIaIYsxc%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093021684%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=cMayR6RKvH2%2FKh1llC2B%2FVc8hYqb%2FGZp6e6eJYlYA%2B4%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093021684%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=i%2FudnLRVQl%2F1me7gmKqmPLOjkvknXiaZWkU8fQxA8Z8%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093031678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0ABmpcHzzqAZovyjgVvTwV2RT%2B1aHl7PaJZEhqPVat0%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093031678%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=0ABmpcHzzqAZovyjgVvTwV2RT%2B1aHl7PaJZEhqPVat0%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093041676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=v7vAxbr2fPhs%2FJWL01dq4Opn7ftNSe4Tb7ldu9A0oxE%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093041676%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BLKX4%2BHs7WjS%2B0WK0kmPfLaVwdp0R7thjwg4Ag4cq5o%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093051665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tAlZLQpfWmkwpVzmhQSZZDdyxDuUj3Cyk9k8Amr1LD0%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093051665%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=faH5BNh0WNzrbOLcdzuGq4V1TPPoXMF%2FrF5blvv04Tc%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402656093061660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=xVvUBNAXhxd%2FudE1LJMa2doBY08CxhLy0cf4O%2FNSZLM%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093061660%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=E42I1d8mNa8IDO8SxpIXbopr7R98GhwhFRYoRQEz4rU%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093071652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=ml7FwrkIIMsASD5G8p2%2FPv%2BiLqV6xWD3nVa%2B7Qg2WV4%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637402656093071652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4cQmaHVrc28IcK3IpdT5BCgpe5JRT1lzbBMzRgK3oZs%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%7C22cd3c6aa01c41a3160108d88256ae03%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637402656093081650%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OapL0eZ5ILC8uc3JAOamBZJ6BLLmZG3%2B95oRv%2BT%2Fq%2FM%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>..."
>> }
>>
>>