Re: The long road ahead

On 08/16/2013 10:46 AM, Dan Brickley wrote:
> It's not a simple matter of 'putting the site onto github'; there's a
> pile of software involved that needs reworking and rethinking before
> it could usefully be shared.

If that's the case, you could throw away the bits that can't be put into
github and start over. Collaborating on schema.org is not scalable as it
stands right now. If this is truly going to be an open project (with the
search companies with the final say on what goes in and what doesn't),
then putting it on github should be one of the highest priorities.

> In general, discussing JSON-LD took time
> out that could have gone on RDFa. 

Right, so this is broken. If you have to put RDFa on hold to talk about
JSON-LD, then it shows that there aren't enough people helping to
maintain the site. If you put it on github, you at least enable the
possibility for this community to help you with some of the more mundane
stuff while also keeping control of what gets into the site and what
doesn't. You have at least 6 volunteers here, with very deep knowledge
of the subject area, that would help improve the site if we could.

> There's also a first cut at RDFa
> versions of schema.org's microdata examples in Mercurial at W3C too.

That's great, but the problem here is that we've been waiting for
examples like that to be integrated into schema.org for over two years
now. I realize that schema.org is understaffed. However, the solution to
that is not to point to software repositories that are tangential to
schema.org, they're to get schema.org into a position where it makes it
much easier for us to help you with it (thus the "put it on github"
comment).

> I'm looking to revisit that idea in a way that would support
> translation into other languages, as well as alternate formats.

Why not offload that work to one of us so that you can focus on more
pressing things?

> Microdata is published on 4+ million domains - reports of its death
> are somewhat exaggerated, and inflamatory talk of 'downward spirals'
> does nobody any favours. 

I never said Microdata was dead. I was very careful to not say that. I
was also very careful not to say anything about schema.org in the post.
What I did do was connect a number of the dots that were already out
there wrt. Microdata and pointed out a trend.

> Microdata deserves a stable specification at
> W3C; whether as REC, NOTE or a .txt file.

Sure, a NOTE will probably happen. That is, however, a bit beside the
point. The point was the general trend around Microdata and the lack of
a supportive community. As we know, when a spec ends up as a NOTE and
there is hardly any community to support the technology, bitrot starts
to set in.

> The Microdata *API* on the
> other hand does indeed appear to be on its way out - but let's try to
> learn from that rather than use it for rhetorical point-scoring. 

We knew what was going to happen to the Microdata API when we stopped
working on the RDFa API. It was going to die because it was not clear
what use case we would be addressing with a library of that nature.

I wasn't doing it for rhetorical purposes, I was pointing out facts
because I was asked to (I was being responsive to someone that wanted to
learn more about the current state of Microdata):

https://twitter.com/stilkov/status/367237073117671424

The facts say that less people are working on Microdata these days. In
fact, the only people that seem to be propping it up now are schema.org.
I realize that all of this puts schema.org in an awkward position, so
rather that focus on that awkward position, let's talk about how we can
improve schema.org such that it serves its community (and provides an
exit from Microdata in the event that the same thing that happened to
Microformats happens to it as well).

> This
> would be a very very good time to revisit the question of a .js API
> for structured data that abstracts away from the question of Microdata
> vs RDFa 1.0 vs RDFa 1.1. Is http://www.w3.org/TR/rdfa-api/ dead? Any
> lessons learned?

The lessons learned were that we didn't have enough information to do a
good job at creating an API, the RDF WG was not prepared to collaborate
on the API, and that any API that we would create would be just as
easily created using a JavaScript shim. We need to give it 2-3 years to
see what happens. Alex Milowski's Green Turtle RDFa processor is the
best bet of finding out what's useful.

Additionally, we think that JSON-LD may be the best way to extract this
data. That's why we supported Microformats, Microdata, and RDFa from day
one. We saw (over 4 years ago now) that there was going to be a problem
w/ JSON interchange, and Web developers like working w/ JSON Data. So,
JSON-LD was designed to be this unified output format for developers.
That is, we think that Green Turtle could parse RDFa, Microformats, and
Microdata and spit out unified JSON-LD, and that would be close to the
ideal format to work with the data.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Meritora - Web payments commercial launch
http://blog.meritora.com/launch/

Received on Friday, 16 August 2013 15:54:43 UTC