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

Superficially:

RFC3161 requires trust to the entity behind the timestamping service  (not
that important for many use cases) while blockchain timestamping is
trustless (depending on use case/implementation).

Blockchain network integrity determines security of the timestamp.
Arguably, a lot of blockchain networks are not good enough.  Extra secure
networks, like the Bitcoin network, can guarantee a timestamp of +-30mins
and not an exact one since miners have some control over the timestamp.


On Fri, Nov 6, 2020 at 6:47 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> 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>..."
>>> }
>>>
>>>

-- 
Konstantinos A. Karasavvas
Software Architect, Blockchain Engineer, Researcher, Educator
https://twitter.com/kkarasavvas