Extending schema.org with GoodRelations - schema.org

The GoodRelations Web site gives a short example on how to extend schema.org with GoodRelations classes and properties.
Unfortunately, the example markup is not valid when testing it with the Google Structured Data Testing Tool.
For this code snippet given as example, the properties "hasBusinessFunciton" and "haspriceSpecification" are not recognized for the "Offer" type.
<div itemscope itemtype="http://schema.org/Offer" itemid="#offer">
<div itemprop="name">Hepp Personal SCSI Controller Card</div>
<div itemprop="description">The Hepp Personal SCSI is a 16-bit add-on card that allows attaching up to seven SCSI devices to your computer.</div>
<link itemprop="http://purl.org/goodrelations/v1#hasBusinessFunction"
href="http://purl.org/goodrelations/v1#Sell" />
<!-- Shipment fees -->
Delivery costs to
<div itemscope itemprop="http://purl.org/goodrelations/v1#hasPriceSpecification"
itemtype="http://purl.org/goodrelations/v1#DeliveryChargeSpecification">
<meta itemprop="eligibleRegions" content="DE">Germany:
<meta itemprop="hasCurrency" content="EUR">Euro:
<span itemprop="hasCurrencyValue">10.00</span>
<link itemprop="appliesToDeliveryMethod"
href="http://purl.org/goodrelations/v1#UPS" />(via UPS)
</div>
<!-- other offer properties follow here -->
...
</div>
Is there some working example of schema.org extended with GoodRelations properties ?
What about using http://wiki.goodrelations-vocabulary.org/Cookbook/Vehicles in schema.org
Cheers

The reason for this is that the examples on the GoodRelations site are not yet updated to reflect the integration of GoodRelations into schema.org (simply because I did not yet manage to do that).
In order to understand this, you need to look at the history of GoodRelations:
http://wiki.goodrelations-vocabulary.org/History
GR started as an independent Web vocabulary ("ontology") and was designed to be used in RDFa or other RDF-syntaxes (like RDF/XML, Turtle, ...).
In 2009, Yahoo started to honor GoodRelations in RDFa syntax, and in 2012 Google followed. Note that this all happened in the original GoodRelations namespace, i.e. with identifiers like
http://purl.org/goodrelations/v1#BusinessEntity
After the announcement of schema.org in 2011, I worked with Google, Bing, and Yahoo to integrate GoodRelations into schema.org, which was completed and released in 2012.
This meant that (almost) any element from GoodRelations would now also be part of schema.org. So GoodRelations is now the official, extended e-commerce model of schema.org.
The result is that every GoodRelations element has now TWO identifiers:
a) the original one, like http://purl.org/goodrelations/v1#OpeningHoursSpecification
b) the one in schema.org, like http://schema.org/OpeningHoursSpecification
In some cases, the local part of the names differs between the original GoodRelations namespace and the derived version of in the schema.org namespace, in order to be consistent with the existing naming conventions in schema.org, or because a similar element had existed before.
For instance, an "Offer" is
http://purl.org/goodrelations/v1#Offering
in the original GoodRelations version, but
http://schema.org/Offer
in schema.org. But the two are the same conceptual element.
For a full list of naming differences, see
http://wiki.goodrelations-vocabulary.org/Cookbook/Schema.org#Naming_Differences
Now here comes the tricky part:
GoodRelations is supported by Google and Yahoo in its original namespace in RDFa syntax, but only in the schema.org namespace in Microdata or JSON-LD, and the support in its original namespace may be a bit out of date.
For enumerations (individuals), the original namespace remains the official one, i.e. all elements from http://www.heppnetz.de/ontologies/goodrelations/v1.html#individuals remain valid in the http://purl.org/goodrelations/v1# ... namespace, e.g. http://purl.org/goodrelations/v1#Cash.
This was chosen because we could reduce the number of new elements for schema.org by keeping the identifiers for values in the original namespace.
So when you are using GoodRelations for search engines, you should use it in the schema.org namespace. The http://purl.org/goodrelations/v1# ... namespace keeps being functional for RDF / Linked Data / SPARQL-based projects.
In the future (likely this year), there will be service update in GoodRelations which will provide
updated examples to reflect this properly and
mapping axioms so that Semantic Web applications will see the equivalences.
Hope that helps!
Best wishes
Martin Hepp
http://www.heppnetz.de

This example is valid Microdata, and also appropriate use of the Schema.org vocabulary.
Google’s Testing Tool is not a validator. It only checks structured data according to Google’s own rules, e.g. what they recognize, or for showing their Rich Snippets.
What’s happening in this snippet: the two properties (http://purl.org/goodrelations/v1#hasPriceSpecification and http://purl.org/goodrelations/v1#hasBusinessFunction) are specified as absolute URLs, which is one of the four valid ways how to provide properties in Microdata.
However, note that Microdata has only limited support for mixing vocabularies. RDFa is way more powerful in that regard. (Related: differences between Microdata and RDFa.)
With RDFa, the snippet could look like this (keeping the same HTML):
<div typeof="schema:Offer" resource="#offer">
<div property="schema:name">Hepp Personal SCSI Controller Card</div>
<div property="schema:description">The Hepp Personal SCSI is …</div>
<link property="gr:hasBusinessFunction" href="http://purl.org/goodrelations/v1#Sell" />
Delivery costs to
<div property="gr:hasPriceSpecification" typeof="gr:DeliveryChargeSpecification">
<meta property="gr:eligibleRegions" content="DE" />Germany:
<meta property="gr:hasCurrency" content="EUR" />Euro:
<span property="gr:hasCurrencyValue">10.00</span>
<link property="gr:appliesToDeliveryMethod" href="http://purl.org/goodrelations/v1#UPS" />(via UPS)
</div>
</div>
(Making use of the prefixes schema, for the Schema.org vocabulary, and gr, for the GoodRelations vocabulary, which are defined in the RDFa Core Initial Context.)

Related

HTML reuse and maintenance with Play! framework

We have been having discussions in our product dev team regarding html maintainability and reuse. To set the context, we started with HTML5/CSS3 front end with plain JS under Play MVC, which in turn uses RESTful backend. Then we thought of adding AngularJS to the spin and to adopting a hybrid approach only to realize that two strong MVC frameworks don't necessarily work together and you have to pick one. So for the performance and type-safety among other issues, we decided to go with using Play framework and Scala based templates.
Here's the challenge: We would like to create reusable web components just like Apache Tiles, so that common elements such as header, menus, footer, etc. can be reused. These components are ready to go in Play to which dynamic content could be added to serve the entire page.
Can this be done? If yes, how?
Secondly, play templates seem to take you back in the time since they don't allow the separation of concern in html. Therefore for re-designing or improving html content, the html developer will have to deal with the template or merging new html with existing templates. How to make this process easier?
I'm don't know exactly how Apache Tiles works, but if I properly understand, it offers a way to create pages using smaller components (like header, menu, footer, etc) and some sort of include mechanism to glue these components together and then compose the page.
That said, you can achieve the same thing using Twirl. You just need to declare reusable blocks that can be used inside the same page, or you can have something like Rails partials that can be reused across different pages.
Let's see an example. Consider that you have the following files:
File app/views/partials/header.scala.html:
<header>
<h1>My Header</h1>
</header>
File app/views/partials/navigation.scala.html:
<nav>
<ul>
<li>Home</li>
<li>Profile</li>
<li>FAQ</li>
</ul>
</nav>
File app/views/partials/footer.scala.html:
<footer>
Some copyright info
</footer>
File app/views/main.scala.html:
#(title: String)(content: Html)
<!DOCTYPE html>
<html lang="en">
<head>
<title>#title</title>
<link rel="stylesheet" media="screen" href="#routes.Assets.versioned("stylesheets/main.css")">
<script src="#routes.Assets.versioned("javascripts/hello.js")" type="text/javascript"></script>
</head>
<body>
#partials.header()
#partials.navigation()
#content
#partials.footer()
</body>
</html>
The files above defines not only some reusable partial templates (header, navigation and footer), but also a common layout (main) that all the pages of your application can reuse. Now, lets see a page that uses the structure above:
File app/views/users/profile.scala.html:
#(user: models.User)
#main(title = "User Profile Page") {
<h2>This is the profile page of #user.username</h2>
}
And there is more: since views are compiled to Scala code, you can import code written in Scala/Java and call it directly from your views, something like Rails view helpers:
File app/views/helpers/DateHelpers.scala:
package views.helpers
object DateHelpers {
def formatToISO8601(date: Date) = {
??? // format the date
}
}
Let's use this helper in our app/views/users/profile.scala.html page:
#(user: models.User)
#import controllers.DateHelpers._
#main(title = "User Profile Page") {
<h2>This is the profile page of #user.username.</h2>
<p>User since #formatToISO8601(user.createdAt)</p>
}
And there are other approaches to consider:
Ping-Play: Big Pipe Streaming for the Play Framework
You can create a Play module that integrate with Apache Tiles. I'm pretty sure this is possible.
A quick answer would be the following. If you are comfortable with Yeoman, you can keep most of the UI part in existing HTML, while rendering some pages with Scala templates. I would recommend Play-yeoman, which may help such that you can--with minimum effort--reuse UI components.
For instance, you may easily convert a NodeJS+Angular app into Play+Angular. The Play-yeoman plugin helps a lot. But it is not so flexible as it does not support any arbitrary Yeoman configuration, just Angular.

GSA: microdata gets truncated

I'm feeding the data of into Google Search Appliance. My feed contains HTML documents enchanced with Microdata from schema.org (specifically this).
To my surprise:
the search results aren't any different to the ones I receive without microdata enhancement in place,
while using test tool, I'm seeing that GSA cuts the Microdata from the markup.
Questions:
How to improve GSA search results?
Why would GSA cut the Microdata from the markup? Should I be concerned about it?
The GSA does not support those microdata.
It typically only supports meta tags under the format <meta name="category" content="computer"/>

Does Google recognize all Schema properties?

According to the CreativeWork Schema, "license" is a valid property, but testing the below code with the Google Structured Data Testing Tool renders an error:
Error: Page contains property "license" which is not part of the
schema
<span itemscope itemtype="http://schema.org/CreativeWork">
<meta itemprop="genre" content="Travel">
<meta itemprop="isFamilyFriendly" content="true">
<link itemprop="license" content="http://creativecommons.org/licenses/by-nd-nc/1.0/">
</span
Am I to assume that this is a glitch in the testing tool, or that Google ignores the property and it is used elsewhere by other SEs?
The license property was added in version 1.6 (2014-06-16).
The Google Structured Data Testing Tool doesn’t recognize many other properties from after and even before this release, so it’s likely that they did not catch up yet.
If Google makes use (or ever will make use) of this property can’t be answered. Neither Google nor other schema.org consumers necessarily make use of all properties and classes, and specific uses might be undocumented or secret.
(Side note: As you have a URL as value of the license property, you must use the link element instead of meta.)

What exactly does currentDesign.writeCssincludes include?

I'm trying to figure out exactly what css is included by the standard call to currentDesign.writeCssIncludes(pagecontext); found in headlibs.jsp. The documentation states simply that it is
Convenience method that writes the CSS include strings to the response.
Looking at what it seems to do, it will include /etc/designs/currentdesign.css which is built off the design components css, and /etc/designs/currentdesign/static.css, which is just a static file. But is this all that is will include?
In particular, what I'd like to do is include a clientLib-processed css file as part of my design. One way to do this is to manually build out the css include:
<link rel="stylesheet" href="<%= currentDesign.getPath() %>/myclientlib.css" />
But I'd prefer to let that get generated automatically, so that my designers have flexibility to structure the css files differently for different designs (i.e., for the "base" design they are fine with just a static.css file, but for the "fancy" design they want to use LESS css and break up the files more granularly). And it would be helpful to put design-specific css info with the components they affect, rather then needing to separate those.
You can use the <cq:includeClientLib> tag, combined with themes and/or categories, to mix and match bits of CSS.
But you may find it somewhat limiting; for instance, you can't specify a media attribute. If you need to do this, or your designers don't structure their CSS in a way that fits the themes/categories model, your fallback is the technique you've identified in your question, using <link> directly.
Update
An excellent question about themes! I have only seen them used in passing.
You can define a theme by just adding a new folder/node under /etc/designs/yourproject/clientlibs/themes, as a sibling to default.
You can pull in the clientlibs for a theme with the <cq:includeClientLibs> tag, perhaps under the control of some conditional logic. For instance, in one of my projects I have a theme called authoring which I only want to apply to the author instance; I pull it in with this code in headlibs.jsp:
<c:if test="${ (global['wcmmode'] eq 'EDIT') || (global['wcmmode'] eq 'PREVIEW') }">
<cq:includeClientLib theme="apps.myproject.authoring" />
</c:if>
I have not seen any documentation that would apply theme automatically to a particular subtree of the content tree, or based on the presence of a tag.
There is that cryptic statement "The theme name is extracted from the request." in the Adobe docs, which is backed up by this statement in the Sling docs, "ThemeResolverFilter Provides the Theme for the request. The theme is provided as a request attribute." So perhaps tacking &theme=apps.yourproject.foo onto a query string would apply that theme.
The list of CSS files is based on the property 'cq:designPath' of the page.

What is CMS/Framework used in both of this website?

Both of this website has similar feature and interface, so I have strong feeling that both of this website built on same CMS/framework:
lintasberita.com
cekberita.com
Its built on PHP
But What is the CMS/Framework used by that website?
Thank you.
<meta name="description" content="Hotaru CMS is an open source content management system, written in PHP." />
Although having looked at that source code, I'm not seeing anything to encourage me to use it.
Of course, the multiple <script> elements, comment before the Doctype, meta description designed to wreck listings in Google, invalid HTML and hideous design could be the author's fault…
In the page source of cekberita.com, there was written in a meta tag: "Hotaru CMS is an open source content management system, written in PHP." So I guess it is Hotaru.