On Thu, Jul 2, 2015 at 11:47 AM, Gordon Brander <gbran...@mozilla.com> wrote:
> 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_ Hmm... I'm not sure Postel was really referring to this kind of case so much as about specification compliance. In any case, I think there's an argument to be made that supporting a lot of format is not a good thing. See also:: http://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ -Ekr > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
