This thread has been fun to follow. There are only 2 hard problems in Comp Sci and naming things is one of them ;).
Just wanted to quickly chip in: during our lively discussion about naming, let’s not forget Postel’s Law. It’s smart to debate which format we should encourage for _publishing_. It’s wise to be liberal in what formats we _accept_. So we can encourage developers to use the solution we think is best, while simultaneously falling back to anything reasonable that’s there. og:x, twitter:y, Microformats... if it’s being actively used on the web we would be silly to turn up our nose at good data! --- Gordon Brander Sr Design Strategist Mozilla On July 2, 2015 at 10:59:15 , Benjamin Francis (bfran...@mozilla.com) wrote: > On 2 July 2015 at 03:37, Tantek Çelik wrote: > > > tl;dr: It's time. Let's land microformats parsing support in Gecko as > > a Q3 Platform deliverable that Gaia can use. > > > > Happy to hear this! > > > > I think there's rough consensus that a subset of OG, as described by > > Ted, satisfies this. Minimizing our exposure to OG (including Twitter > > Cards) is ideal for a number of reasons (backcompat/proprietary > > maintenance etc.). > > > > That's certainly a good start. It seems a shame to intentionally filter out > all the extra meta tags used by other Open Graph types like: > > - music.song > - music.album > - music.playlist > - music.radio_station > - video.movie > - video.episode > - video.tv_show > - article > - book > - profile > - business > - fitness.course > - game.achievement > - place > - product > - restaurant.menu > > I envisage allowing the community to contribute addons to add extra > experimental card packs for types we don't support out of the box from day > one. Filtering out this data would make it very difficult for them to do > that, for no good reason. > > I absolutely understand the argument about having to maintain backwards > compatibility with a format if we don't want to promote it going forward > though, which is why I agree we should be conservative when adding built-in > Open Graph types. > > There appear to be multiple options for this, with the best (most > > open, aligned with our mission, already open source interoperably > > implemented, etc.) being microformats. > > > > That is your opinion. There may be things you don't like about JSON-LD for > example, but it is a W3C Recommendation created through a standards body > and has open source implementations in just as many languages as > Microformats. There may be other more subjective measures of "open" you're > talking about, but I think it would be better for us all to stick to > arguments about technical merit and adoption statistics when making > comparisons in this case, at the risk of falling into the Not Invented Here > trap. > > > > "fulfils" mostly in theory. Schema is 99% overdesigned and > > aspirational, most objects and properties not showing up anywhere even > > in search results (except generic testing tools perhaps). > > > > > A small handful of Schema objects and subset of properties are > > actually implemented by anyone in anything user-facing. > > > > As I mentioned, level of current usage is not the most important criteria > for Gaia's own requirements, but if we're talking about how proven these > schemas are, according to schema.org these are the number of domains which > use the schemas we're talking about: > > - Person - over 1,000,000 domains > - Event - 100,000 - 250,000 domains > - ImageObject - over 1,000,000 domains > - AudioObject - 10,000 - 50,000 domains > - VideoObject - 100,000 - 200,000 domains > - RadioChannel - fewer than 10 domains > - EmailMessage - 100 - 1000 domains > - Comment - 10,000 - 50,000 domains > > The only equivalent data I have for Microformats is for hCard (equivalent > to the Person schema) from a crawl at the end of last year [1], and it has > about the same usage: > > - hCard - 1,095,517 domains > > The data also shows that Microdata and RDFa are used on more pages per > domain than Microformats. > > I'd say that Microformats looks at best equally as unproven on that basis, > though I'm open to new data. > > > > Everything else is untested, and claiming "fulfils these use cases" > > puts far too much faith in a company known for abandoning their > > overdesigned efforts (APIs, vocabularies, syntaxes!) every few years. > > Google Base / gData / etc. likely "fulfilled" these use cases too. > > > > Our Gecko and Gaia code is not going to stop working if Google decides to > use something else. Content authors on the wider web might migrate to newer > vocabularies (or even syntaxes) over time, but that's something we're going > to have to monitor on an ongoing basis anyway. > > Existing interoperably implemented microformats support most of these: > > > > - Contact - http://microformats.org/wiki/h-card > > - Event - http://microformats.org/wiki/h-event > > - Photo - http://microformats.org/wiki/h-entry with u-photo property > > - Song - no current vocabulary - classic hAudio vocabulary could be > > simplified for this > > - Video - http://microformats.org/wiki/h-entry with u-video property > > - Radio station - no current vocabulary - worth researching with > > schema RadioChannel as input > > - Email - http://microformats.org/wiki/h-entry with u-in-reply-to property > > - Message - http://microformats.org/wiki/h-entry > > > > OK, so there are actually three Microformats that are useful to us here. > For photos, videos, emails and messages we have to re-use the same hEntry > Microformat and try to figure out from its properties which type of thing > it is. For song and radio station we'd need to invent something new. > > This is not very attractive for Firefox OS where we'd like to have cleary > defined types of cards with different card templates. It also makes it > harder for the community to create new types of cards (e.g. via addons) > because they have to reason about "an h-entry with a u-video property" vs. > just a "VideoObject" and have to deal with the ambiguity of "an h-entry > with both a u-photo and u-video property" which could either be a video or > a photo. > > An explicit type is important because in our UI we try to say "Pin > Contact", "Pin Photo" or "Pin Video" rather than just "Pin Page". > > > > The "actions" space has been a difficult and challenging one. > > > > Google's (abandoned) "web intents" was one such effort. > > > > Yes we've had a similar experience with Web Activities. > > > > Currently the IndieWeb community is pursuing Web Actions (and has them > > working across sites) > > > > http://indiewebcamp.com/webactions > > > > There's likely potential there to connect webactions to be part of the > > format of the post/page to be parsed, consumed, re-used. > > > > I agree with Kelly's impression of this. It seems like it's at a very early > stage and loosely defined (even compared with the Action schemas), and I'm > not sure it's trying to solve the same set of problems we're trying to > solve. I don't think this is going to solve our use cases for 2.5. > > It's not just that, but the experience (that any Mozilla engineer who > > was here before Firefox will relay, e.g ping jst sometime if you want > > to hear horror stories) of RDF, triple-stores etc. being a disaster > > for Mozilla, performance, etc. and taking ages to undo. > > > > I want to emphasise here that we are not trying to build an RDF parser or > pursue any grand Semantic Web vision. We're just trying to extract user > value from existing metadata on the web by saving a bit of extra JSON in > the Places database and using it to build a richer representation of web > content in our UI. > > > > In practice, if you're actually bothering with JSON-LD (not just plain > > JSON), and using or depending on anything triples related, you're > > likely to run into similar problems and objections. It's a very high > > risk path. If you're ignoring all the "LD"ness of JSON-LD, then just > > admit that upfront and use some one-off JSON. > > > > I don't want to invent something new if we can avoid it. We've already > invented plenty of new APIs on the B2G project which have not made it onto > a standards track. I want to make a better user agent by creating user > value from the metadata and formats which are already in use on the web. > > I agree with Jonas that the vast majority of this work can be done in Gaia, > we just need a couple of new events on the Browser API which Kan-Ru says he > is happy with being landed. A lot of our Gaia requirements could be > fulfilled by existing Open Graph types if we wanted to re-use those as > Jonas suggests, and we also have the option of creating our own namespace > for additional types. If we were to go down that route we would definitely > need more than the four simple meta tags. > > I think there are going to be some missing use cases just using Open Graph > alone though, particularly with regards to actions which are actually more > of a Linked Data type thing (not just metadata). JSON-LD is an easy tool > for us to play around with for this, which is why I'd like to move forward > on making the small change to the Browser API that would be needed for us > to do that. > > I'm very happy for the Microformats work to continue in parallel so that > Gaia developers can use it when it's ready, but the evidence I've seen so > far has not convinced me that it's a great fit for all of our requirements > and it's too much of a risk for us to put all of our 2.5 eggs in that > basket. > > So let's move forward on both the Browser API events to give us some > flexibility to start experimenting in Gaia, and the Microformats > implementation in Gecko so that we can evaluate that properly going forward. > > Thanks > > Ben > > P.S. I'm curious whether Microformats has ever been proposed as a > specification to a standards body like the W3C or WHATWG? It seems like it > could benefit from some additional feedback from outside its existing > community. > > 1. http://webdatacommons.org/structureddata/2014-12/stats/stats.html > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
