Support GoodRelations

Yep, Good Relations is on the radar, and it's great to hear that Google will be supporting it. : )

We have some discussions on DC.org about this, I think, and we should ping bojanz to see if he thinks he can find time to get on it. : D

Aside from him or others contributing this, I won't be able to get to it personally until we reach beta. Thanks for making the issue, though - will use this issue to track RDF progress from here forward.

Gonna put this bookmark here, as it deals with canonical product URLs in Good Relations:

http://ebusiness-unibw.org/pipermail/goodrelations/2010-August/000248.html

Sorry, I'm definitely planning to do this.
University and efq_views got in the way, but efq_views is now pretty much done, so that should not be a blocker anymore.

Will look into it this weekend, and report back for discussion if parts prove to be non-straightforward.

hehe No worries. I knew you were busy, and I just saw your blog post come through on EFQ Views. Congrats on all the work, you're doing great! : )

Thanks Ryan, I appreciate it :)

Okay, so let's start discussing this. I'm a total noob when it comes to GoodRelations, so I'm gonna need help.

I figure the start looks something like this:

/**
 * Implements hook_rdf_namespaces().
 */
function commerce_product_rdf_namespaces() {
  return array(
    'gr' => 'http://purl.org/goodrelations/v1#',
  );
}

/**
 * Implements hook_rdf_mapping().
 */
function commerce_product_rdf_mapping() {
  return array(
    array(
      'type' => 'commerce_product',
      'bundle' => RDF_DEFAULT_BUNDLE,
      'mapping' => array(
        'rdftype' => array('gr:Offering'),
        'title' => array(
          'predicates' => array('gr:name'),
        ),
        'created' => array(
          'predicates' => array('gr:validFrom'),
          'datatype' => 'xsd:dateTime',
          'callback' => 'date_iso8601',
        ),
        'sku' => array(
          'predicates' => array('gr:serialNumber'),
        ),
        'purchase_price' => array(
          'predicates' => array('gr:hasCurrencyValue'),
          'datatype' => 'xsd:float',
        ),
      ),
    ),
  );
}

Questions & Notes (for me, you, Lin, everyone else):
1) Do we only do this for commerce_product? Or do we expose "customer" too? Maybe for (currently non-existing) reviews?
2) We have the price as "gr:hasCurrencyValue", that's the amount without the currency code. However, we also need the currency code itself as "gr:hasCurrency". That needs to be somehow exposed through fields.
3) I'm running the commercedev install profile, and commerce_product has an image there. That image is not part of the module install itself, right? If it were, then we could have exposed it too.
4) The gr vocabulary is added successfully with the code above, but the rdf for commerce_product is not included in the node referencing the product (need to see how we should do this)
5) Lin's link recommends adding about="#review_data" all over the place. How to do that with Drupal?

In general, commerce_product is pretty spartan, so we can't support by default the various crazy options that GoodRelations gives us (which is kind of a bummer..)

Double posted somehow...

Returning tag.

Today's conference call helped a lot, cleared up many dilemmas, and revealed areas I hadn't even considered yet.

Quick notes before I fall asleep at my keyboard:
1. We need a robots.txt file pointing to a sitemap that has a list of rdf content (our products) and their validity time. The validity is essential. Does the Drupal RDF support (core or module) have at least the beginnings of this?
2. We need a cron function that pings the gr-notify web service once a day (or more/less). This way the service is notified that there's new GoodRelations content available at the given URL. The gr-notify service forwards the notification to other important services that do the same thing, so we don't have to implement others.
3. We need a way to find out which payment processors Drupal Commerce supports, to that we can include that info in the markup. This list is fixed in GoodRelations and looks like this:

ByBankTransferInAdvance, ByInvoice, Cash, CheckInAdvance, COD, DirectDebit, PayPal, AmericanExpress, DinersClub, Discover, MasterCard, VISA

A payment provider module could declare that it supports a certain option from the list above, or we could just give the user a list of checkboxes to select.
4. Each product must have a validity, and each price must have a validity.
The recommended validity for products is 7 days, and 1 day for prices (?!)
Not sure whether the validity is supposed to be automatically updated each day, or if it's better to leave it "invalid".
I think one of the reviewed extensions (for Joomla or Magento) updates it each day. This needs to be discussed more.
5. There are two options for multilingual content, that correspond to the two future Drupal core options for multilingual content.
In both you provide rdfa markup for title and description, and indicate the language used.
a. If we have one node per language (the D6 way), then we use the "sameAs" property to point from a translated node to the default language node, preventing the duplication of data.
b. If we have multilingual fields (the future way that sun is working on in Translation) then we don't need the "sameAs" property. Since that approach is still very young, I won't go into details about handling it (there are still fuzzy details there...)
6. Each product must have a company associated with it, and that info will be inputed in a settings form. A store is only specified if it's a real physical store, and it is optional. This should also be supported.
7. The current "product switcher" won't do. Other than the fact that it doesn't work without javascript, it also makes GoodRelations markup impossible.
What could be done (and might just work) is switch to a #states based approach:
Both products (assuming two products referenced) are present on the page and with rdfa markup, shown&hidden by using #states on the select box.
Each product has it's own add to cart button that's wrapped in noscript tags, so it's shown only if JS is off and both products are displayed.
The current switcher&add to cart button is wrapped in a hidden div and shown via Javascript, so it's present only if JS is enabled.

8. Once you have more than one product in a node, things with GoodRelations get messy.
One option is to just output rdfa markup for both. However, Google chokes on this and doesn't show the "smart snippet" in the search results, therefor nulling the advantages of using GoodRelations in the first place.
The other option is to "group" them, so you have markup that says: T-Shirt S,M, XL; prices: from 10$ to 30$.
The problem with this is that we can't be sure that all products are variations (we allow pretty much anything), so there would have to be a checkbox saying "These referenced products are all variants of the same thing, please group them in markup" or something like that ;)

Of course, the best option is to have canonical URIs (one URI per product), but the current architecture makes that pretty much impossible.

9. There are two ways of providing RDFa markup:
a. First is through properties on the elements surronding the content, this is the current Drupal 7 way.
b. The second is by using snippets, empty divs with properties giving the information. These are not human readable, and look like this:

<span property="vcal:tel" datatype="xsd:string" content="Bojan's phone number"></span>

The snippets are less desirable than the current solution, but necessary in some cases, since not all of the data needed is coming from fields (we need the currency the company stored in settings, the accepted payment methods, the calculated validity...). Also needed when "grouping products", and in that case we'd need to surpress the default output given by the Drupal RDF layer.
Martin says that when the snippets are close to the actual content, Google doesn't penalize.

10. We must only include the full GoodRelations markup on full node view. When in a View, the only markup allowed is for title and description.
In general, the full node view markup is the important one, the markup in lists is just bonus.

That's it. Now we need to discuss the technical/implementation/drupal side, so I'm mostly interested in what Lin & other RDF wizards have to say.
My current thought is maybe to go around the drupal rdf hooks & mappings and do the output myself. Hacky, but mostly needed. VERY interested in better alternatives.

We have access to the Joomla, Magento & Wordpress extensions, for inspiration and discussion. The most recent & most awesome & recommended one is the Wordpress one.

Regarding #1:
The sitemap.xml required has nothing goodrelations specific, so just recommending xmlsitemap is enough.
Our module should have an additional snippet that does the following:
When a product is updated, all nodes (hopefully only one) that reference that product are updated too (we just run node_save() to update the last modified timestamp. Then xmlsitemap kicks in and updates the sitemap).
--------

Not really sure whether we can support good relations on category (product listing) pages.
Sure, we can alter taxonomy pages and insert rdfa snippets for each product, but what if the taxonomy is displayed through a view (a common use case)?
In any case, it's something that should be done after the initial version is up and running.

Regarding #1, you raise a good point - where exactly should this code go? : D

It seems like we can bake some GoodRelations support into the core modules themselves but that we might need an additional module to take care of general tasks like this. I'm comfortable with that being a contrib, primarily so it can develop and change more rapidly than the core code. Obviously the module would get bundled into any distribution, so it would be one of those "critical non-core" modules that the project overall supports. Interested in your opinion.

Is #3 showing the full list of options Goodrelations supports? It's interesting that it seems to be a mix of payment methods / individual payment providers... If there's a definite list of options available, it might make sense to bake that into the Payment module.

Re: #7, the product switcher definitely needs some work to make sure it's degradable. Once that happens, though, I wonder what we can do about a solution that is consumable by web services. I'd like to avoid the hidden button approach, as there can feasibly be many referenced products (one site in development has thousands) per node.

On #8, perhaps our plans would be served by roadmapping our support for different types of store configurations. Obviously the starting point would be 1 node : 1 product, and we can have as a postponed item a solution for 1 node : many products. If a simple solution presents itself, we can add it in, but if it appears too complex we can make it a 2.0 feature. I'm thinking we'll have a Commerce 2.0 shortly after DrupalCon London right now, anyways.

Thanks again for getting in on that call and providing the report. I was pretty busy last week, so your help is very much appreciated. : )

Regarding #1, you raise a good point - where exactly should this code go? : D

It seems like we can bake some GoodRelations support into the core modules themselves but that we might need an additional module to take care of general tasks like this. I'm comfortable with that being a contrib, primarily so it can develop and change more rapidly than the core code. Obviously the module would get bundled into any distribution, so it would be one of those "critical non-core" modules that the project overall supports. Interested in your opinion.

I forgot to mention that, I've already started commerce_goodrelations and will push it to github as soon as it gains a bit more shape. This is where the gr-notify pinging is happening, the xmlsitemap update, the settings forms, adding snippet markup for companies (data that might only be visible in markup and not in the page itself), etc.
Some of the rdf mappings could be moved afterwards to their Drupal Commerce modules, not doing that right now because I'm quite unsure about the usefulness of such mappings with commerce_goodrelations disabled (since the module provides all the missing pieces needed to make the goodrelations support complete).

After the module matures on GitHub, we can include it in Drupal Commerce (modules/), keep it in contrib and link to it, or whatever else comes to mind, your call. The important thing is having something that works and that people can download and install :)

Is #3 showing the full list of options Goodrelations supports? It's interesting that it seems to be a mix of payment methods / individual payment providers... If there's a definite list of options available, it might make sense to bake that into the Payment module.

Yes, that's the complete list taken off the goodrelations site. I think I will keep it in commerce_goodrelations since it's pretty much goodrelations specific, hence useless for other modules.

Re: #7, the product switcher definitely needs some work to make sure it's degradable. Once that happens, though, I wonder what we can do about a solution that is consumable by web services. I'd like to avoid the hidden button approach, as there can feasibly be many referenced products (one site in development has thousands) per node.

I agree. It's something that needs brainstorming, my suggestion was the first thing that popped into my mind. The important part is having all products visible in page markup even if they are not shown on the screen (if they should all be consumed by web services...)

On #8, perhaps our plans would be served by roadmapping our support for different types of store configurations. Obviously the starting point would be 1 node : 1 product, and we can have as a postponed item a solution for 1 node : many products.

We can easily handle the "1 node : 1 product" and "1 node : variations of the same product" scenarios. We can revisit the "1 node : multiple different products" once we have the product switcher in a better shape (which could be 2.0)

Thanks again for getting in on that call and providing the report. I was pretty busy last week, so your help is very much appreciated. : )

Glad to be able to help ;)

For reference, 3 GoodRelations extensions were released recently, see the annoucement: ANN: Three sophisticated RDFa extensions for Magento, Wordpress, and Joomla/Virtuemart

Subscribing...

subscribing...

Any progress on this?

.

Stéphane Corlosquet (scor) said during DrupalCon Denver (a week ago) that he has started working on this. So we'll probably see something soon.

Hi Any news on this in relation to rich snippets please?

Hi, I saw: http://bxl2011.drupaldays.org/bxl2011.drupaldays.org/node/293.html

EDIT: slides of this presentation: http://bxl2011.drupaldays.org/bxl2011.drupaldays.org/sites/default/files...
and on this page there is a alpha version..http://notes.3kbo.com/drupal-commerce

Thanks a lot in advance for your update!
Greetings, Martijn

.

subscribing

subscribing

@re-present — Stop subscribing, start following

I've created a contrib module which adds Good Relations support to Drupal Commerce: https://drupal.org/project/commerce_goodrelations. Closing this issue, please file issues there if you find bugs. thanks!

Wow, awesome news Stéphane. Thanks for posting. : )