Remove RDF Module

[quicksketch]

sub-issue from #7

[sun]

The others are fine (and partially long overdue), but I'd recommend to keep RDF module - unless the idea is to re-implement it as an inherent/built-in part of core (without a module). The latest and greatest code from D8 (based on schema.org) would be best. IMO, this topic should play a key role in any CMS today.

[carlwiedemann]

+1 for removal.

[quicksketch]

@sun, I agree that supporting meta data is definitely important, but RDFa was just the the wrong player to bet on as it turned out. Google gives a reason for not RDFa here:

https://support.google.com/webmasters/answer/1211158?hl=en

I think it's criminal that Drupal outputs all this RDFa business, but it doesn't actually have an impact on search listing (that we know of). A simple start for things like supporting OpenGraph and meta tags for icons and thumbnails would have a real benefit users can see today.

[sun]

My knowledge is certainly limited in this field, but I definitely do know that Google's claims were fully disproved in a d.o issue (but unfortunately I can't remember which).

Google interprets and understands both microformats and RDFa equally well. The choice between both is a religious war that not even proficient domain/field experts (i.e., scor vs. linclark → battle!) can get an agreement on or make any sense of. Both sides have a never-ending list of very good and solid arguments. In short: It's a mess.

linclark actually developed the (fully working) microformats module in contrib as a contender to the rdf module in core. Both sides appeared to be very happy again when rdf module in core moved to schema.org namespaces.

Architecturally and markup-wise, the RDFa way of annotating things always made slightly more sense to me. Primarily, because microformats allow each and every vendor to come up with their own set of crap without any wrapping "boundaries". But personal opinions like this are not helpful. → It's a mess. ;)

I'm certain our two lovely semantic web experts are able to share much more meaningful input on this topic. In the end, what should matter most from a web CMS project perspective is to get this technology into the very heart of the entire application - as opposed to a module, which IMO is one hard point where Drupal failed.

[davereid]

Know what most people actually want? Open Graph and Twitter Card support, likely not RDFa.

[acouch]

RDFa is parsed and understood by Google Rich Snippets: http://www.google.com/webmasters/tools/richsnippets?q=http%3A%2F%2Fdemo.getdkan.com%2Fdataset%2Fafghanistan-election-districts

Long-term Google has said it will support RDFa 1.1 (rdfa lite) which similar to microdata, is supported in contrib land: https://drupal.org/project/rdfa

The rdfa/microdata utility is pretty specific (reviews, restaurants, etc), while OG and TC are necessary for almost every web page.

[sun]

@davereid That's bold. Please note that I'm just trying to help by sharing knowledge and experience I gathered through core work here. It might have sounded as if I'd defend rdf module, but that is not the case. The only point I'm trying to make is that semantic web features are important for any web CMS in today's world. There's a plan for removal, but there does not seem to be a plan for how to do it better. Please correct me where I'm wrong. :)

To quickly advance on that: While customer requirements certainly play a key role; once you reach a certain amount of adoption and distribution, an additional stake-holder enters the game: Responsibility for driving the web forward, for the better. Sometimes, the more popular approach is not necessarily the sustainable approach for the web at glance. Finding the right balance between both and the right answer is the challenge.

That said, I'm actually surprised that I never heard anyone thus far who proposed to simply do both at the same time. — After all, there are always simple answers. If deeply integrated into of the core architecture, and if done well, I doubt that any site developer would actually notice.

[quicksketch]

Current pull request fails merging. Marking needs work. Please update tags after this has been updated.

[quicksketch]

I merged in https://github.com/backdrop/backdrop/pull/80 which finished up this issue, but I realize I hadn't addressed @sun's comments.

One of the drivers in this (and other similar "remove x module" issues) is to reduce our overall code maintenance. So far, it's looking like we're going to be working with significantly fewer development resources than we're accustomed to in "normal" Drupal development. I'd still love to see us implement more semantic markup in Backdrop, but RDFa (through a module) probably wasn't the right/easiest way to accomplish this. Rather, I'd like to see schema.org tags implemented directly in various modules that are responsible for output (i.e. image.module, file.module, and even system.module). The attempt to globally append generic meta-data to everything with a single module seems ineffective and inefficient at the same time. Let's move towards more integration in individual issues where we have concrete suggestions.

[sun]

Thanks for addressing the concern.

Yes, the interpretation and summary is correct. All I wanted to point out is that there is a plan for removal, but no plan for doing it better.

Sometimes, success can be driven by removing ballast and re-starting from scratch. Drupal should have done that for a range of other topics (given that it breaks backwards-compatibility anyway).

However, with regard to this issue, I'm concerned that Backdrop will be stuck in endless best practice and standards wars. Drupal went through years of discussion on this topic before already. There is an even 50% distribution among in-depth field experts (and by that, I mean field experts). In turn, there is no concrete hammer for product management to make a truly informed decision.

Furthermore, I'm concerned that Backdrop will actually deviate from getting back to the drop and listen to consumer needs only. Every modern CMS has the responsibility to think beyond its own plate, and make decisions that are best for the web at glance.

Responsibility can mean to make a decision that may not solve the needs of 80% of consumers. That level of thinking is taken for granted when it comes to security related issues. However, the earlier days of Drupal involved this thinking for almost all product decisions. In fact, there are a range of examples that could be listed here, but it would take me too much time to deliver references and proof right now. Drupal definitely did not choose the most popular approaches in its history; it chose the approaches that were best for the web, with, I think, a ~60% hit rate.

So, perhaps, to summarize:

1. We agree that this functionality is required for any modern CMS today.
2. We agree that this level of functionality should be an inherent part of core.
3. Aside from removing the existing feature, there is no idea or plan for how to re-implement it in a better way.
4. Despite that, perhaps I missed something, but I'm not aware of any actual complaints from developers/users/themers who got confused or embarrassed by the current implementation. (?) (Removing RDF module was not even remotely on the plate for Drupal?)
5. By removing the current incarnation, hope is targeted towards a new + revised implementation that lives directly in core, which in turn means that all modules + themes have to be aware of it (yet another API change that Backdrop generally tries to avoid for 1.0).
6. Even though the goal of "native core feature/requirement" is clear, there might be a (massive) dissent in which standards/approaches to implement, support, and follow in the future.

In other words, a huge can of worms.

From a technical perspective, there's little wrong with the current implementation. It does not really matter whether things are annotated through a module or through a built-in core facility; same result. Conversely, the part that does matter is the architectural plan and concept for the resulting product.

[quicksketch]

We agree that this functionality is required for any modern CMS today. We agree that this level of functionality should be an inherent part of core.

I should say we only agree that handling some kind of meta-data as part of the markup is needed. The beef I have with RDFa module is that it doesn't provide valuable meta-data for the sites that use it. Take the following examples:

• Facebook OpenGraph tags (used by Facebook and Google)
• Google authorship
• meta tags (description, keywords, etc)

All three of these don't even need inline-markup at all, such as RDFa provides. The markup RDFa does provide, doesn't provide any direct value to end-users. It doesn't result in any enhanced search listings, and the approach used by RDFa module doesn't even apply to these concepts.

RDFa module does line up with many schema.org implementations, but clearly it's not the appropriate place for schema.org implementations (considering the name of the module).

I agree that it'd be nice to have better implementations of these things, but RDFa module doesn't get us any functionality that is useful to the sites that enable it. For our 1.0 release, I wouldn't be disappointed to not include this functionality; it's a nice-to-have. Since RDFa as-is doesn't provide the value to balance it's maintenance, it gets the ax.

[linclark]

On a somewhat related note in Drupal 8, Why Drupal 8 should drop RDFa (and microdata) in favor of JSON.

If Backdrop wants to have support for rich snippets like Events, might want to look into embedding JSON.

[quicksketch]

Thanks @linclark! I have to admit that your passion for removing RDFa module motivated @jenlampton and I to remove it from Backdrop. If D8 takes this approach I'll be interested to see what kind of benefits the alternative approaches can provide.

For others looking to follow the resulting Drupal discussion, here's the link: https://drupal.org/node/2152459