Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
110 changes: 67 additions & 43 deletions core/templates/core/about.html
Original file line number Diff line number Diff line change
@@ -1,61 +1,85 @@
{% extends "core/layouts/base.html" %}
{% block head_title %}
About Schemas.pub
About Schemas.pub
{% endblock %}

{% block page_content %}

<main class="about-page">
<h1>About Schemas.Pub</h1>
<div class="main-content">
<p>
Schemas.pub is a project of the <a href="https://dtinit.org">Data
Transfer Initiative</a>, built and hosted to promote interoperability
and consistency especially in personal data transfer.
</p>
<main class="about-page">
<h1>About Schemas.Pub</h1>
<div class="main-content">
<p>
Schemas.pub is a pilot project of the <a href="https://dtinit.org">Data
Transfer Initiative</a>, built and hosted to promote interoperability
and consistency of data exchange, especially for personal data transfer.
</p>

<p>
There are a few data types we mostly know how to exchange over the
Internet. Individual calendar items, tasks and contacts can be exchanged
interoperably as files or email attachments, thanks to standards
written in 1998: iCalendar
(<a href="https://www.rfc-editor.org/rfc/rfc2445">RFC2445</a>) and
VCard (<a href="https://www.rfc-editor.org/rfc/rfc2425">RFC2425</a>).
Since 1998, standards like that are not very common. While XML and
JSON have both made defining structured data formats
much easier, as well as schema languages like
<p>
There are some data types we exchange over the Internet quite frequently
and successfully: calendar items, tasks and contacts for example. The
standards for
<a href="https://www.rfc-editor.org/rfc/rfc2445">calendar items</a>
and <a href="https://www.rfc-editor.org/rfc/rfc2425">contacts</a>
were written in 1998, and since then, similar standards are not very
common.
If you take a look at those standards, they use a distinct data format,
which
made them a lot more work to define.
</p>
<p>Since then, JSON and XML have made basic data formatting much more
interoperable
and schema languages for those formats have emerged. <a
href="https://json-schema.org/">JSON Schema
</a> and other schema languages for JSON can quickly and easily show
what
some data consumer expects in a particular data file, and
<a href="https://www.w3.org/TR/xmlschema11-1/">XML Schema Definition
Language</a> and <a href="https://json-schema.org/">JSON Schema</a>,
this has not resulted in an easier job defining any given schema as a
standard.
In fact, XML/JSON and Schemas have encouraged the proliferation of
"unilateral" data definitions -- Web APIs withs schemas defined
solely by the host
of that API, Thus, pretty much every service that hosts
common data (like photos in albums on the Web!) uses different schemas.
Sometimes parts of these APIs use <a href="http://schema.org">schema.org</a>,
which is great and helps a lot with consistency (and accessibility, and
internationalization) of individual fields.
</p>
Language</a> does the same for XML.
</p>
<p>
Why has the emergence of such widespread data format standards and
schema
languages
not made it <i>easier</i> to define a standard? Why do we have no widely
interoperable standard for "an online photo album"
or "a restaurant reservation"? Instead of making it easier to
define standards, XML/JSON and schema languages have encouraged the
proliferation of "unilateral" data definitions -- Web APIs with schemas
defined unilaterally by the designer and host
of that API. Thus, pretty much every service that hosts
common data (like digital photos in albums, or restaurant info and
reservation data!) uses different schemas.
(Sometimes parts of these APIs use <a
href="http://schema.org">schema.org</a>,
which is great and helps a lot with consistency, accessibility, and
internationalization of individual fields.)
</p>

<p> Is this really a problem? In practice consumers of APIs just
<p> Is this really a problem? In practice consumers of APIs just
translate API data into their own format, sometimes aided by schema
definitions and sometimes not. Yet, we think this could be made
definitions and sometimes not. Yet, we think this could be made
somewhat better by allowing organizations to publish schemas that
have some real thought behind them, alongside tools for using
and applying those schemas, and reputational markers to show which
data schemas have implementations, interoperability, open licenses
or standards governance. We welcome your thoughts.
</p>
or standards governance. We welcome your thoughts.
</p>

<p> As of launch, schemas.pub is a fraction of the functionality and
registry size that we envision eventually. We're building the site
<p> The pilot version of schemas.pub is a fraction of the functionality
and registry size that we envision eventually. We're building the site
as we learn about what's most useful to publishers of schemas
as well as implementers searching for solid information.</p>
as well as implementers searching for solid information. We think
persistent URLs for schemas are difficult but useful and if
your organization could use persistent URLs for stable schemas,
<a href="https://docs.google.com/forms/d/1yPMuDri2VLWdv0WW6gj_GPA7xOSg-Nqc7_nfTJmabQg"
>contact us</a>.
</p>

<p>To get started, search for a schema you're interested in and see
how it's defined, some examples, and how it's implemented. If you have
a schema you think should be listed, <a href="{% url 'account_signup' %}">create an account and add it.</a></p>
</div>
</main>
<p>To get started, search for a schema you're interested in and see
how it's defined, some examples, and how it's implemented. If you have
a schema you think should be listed, <a
href="{% url 'account_signup' %}">create an account and add it.</a>
</p>
</div>
</main>
{% endblock %}
8 changes: 6 additions & 2 deletions core/templates/core/partials/footer.html
Original file line number Diff line number Diff line change
@@ -1,4 +1,8 @@
<footer class="site-footer">
<div><a href="/about">About</a></div>
<div>&copy; {% now "Y" %} <a href="https://dtinit.org">Data Transfer Initiative.</a></div>
<div>
<a href="/about">About</a>&nbsp;&nbsp;
<a href="https://docs.google.com/forms/d/1yPMuDri2VLWdv0WW6gj_GPA7xOSg-Nqc7_nfTJmabQg"
>Contact</a></div>
<div>&copy; {% now "Y" %} <a href="https://dtinit.org">Data Transfer
Initiative.</a></div>
</footer>