"description" vs. "reviewBody" for Review - schema.org

I am wondering what is the right Schema.org use for a review in a product. I see two different suggestions:
Majory of sites I've checked use this structure:
"review": {
"#type": "Review",
"author": "Daniela",
"datePublished": "2016-11-01",
"description": "Fantastic product! It really helped me. I would recommend to all my friends and family.",
"name": "Awesome!",
"reviewRating": {
"#type": "Rating",
"bestRating": "5",
"ratingValue": "5",
"worstRating": "1"
}
}
And it's correctly validated in structured data test tool.
However structured data helper and docs show this format:
"review" : {
"#type" : "Review",
"author" : {
"#type" : "Person",
"name" : "Daniela"
},
"datePublished" : "2017-06-08",
"reviewRating" : {
"#type" : "Rating",
"ratingValue" : "5",
"bestRating" : "5",
"worstRating" : "0"
},
"reviewBody" : "Fantastic product! It really helped me. I would recommend to all my friends and family. "
}
They are similar, the only big difference is description vs. reviewBody.
Which is correct?

They are different properties:
description gives a (typically short) description/summary/teaser of the review
reviewBody gives the full review
There is no reason to choose only one here. If you have the data for both, you can use both properties.
For Google’s Review rich result, simply check the documentation:
for a "Critic review", description is required
for a "Review snippet", reviewBody is recommended

Related

Simple JOLT transformation. Add one level and paste part of attributes here

Please, help to modify next json. I need add one level and paste part of attributes here.
Input:
{
"Name" : "Some order",
"Status" : "New",
"Project" : "Some project",
"Goal" : "Some goal",
"Urgency" : "",
"URL" : "",
"table_name": "Order"
}
Desired output:
{
"row": {
"Name" : "Some order",
"Status" : "New",
"Project" : "Some project",
"Goal" : "Some goal",
"Urgency" : "",
"URL" : ""
},
"table_name": "Order"
}
If you have some cool sources about JOLT, please, share.
You can use the following shift transformation spec
[
{
"operation": "shift",
"spec": {
"table_name": "&",
"*": "row.&"
}
}
]
where you just need to nest the elements under row key other than the element with table_name key. &(&0) represents the nearest key(without going up any level, eg. in that case you would need to use &1,&2...etc in order to go 1,2,.. levels up)
You can check this site out as a nice reference.

Mass-reversing smartsheet mistake

Someone managed to copy and paste a huge amount of data into the wrong place in smartsheet. Of course it wasn't reversed at the time, and now I have the lovely task of reversing out all of the entries. Manually. One cell at a time.
There has to be a better way.
Take a look at the Get Cell History endpoint on the Smartsheet API. When you call that you'll get a response back that looks like this:
{
"pageNumber": 1,
"pageSize": 100,
"totalPages": 1,
"totalCount": 3,
"data": [
{
"columnId":4567890123456789,
"displayValue": "Revision 3",
"columnType": "TEXT_NUMBER",
"value": "Revision 3",
"modifiedAt": "2013-06-24T00:10:18Z",
"modifiedBy" : {
"name" : "Jane Smart",
"email" : "jane.smart#smartsheet.com"
}
},
{
"columnId":4567890123456789,
"displayValue": "Revision 2",
"columnType": "TEXT_NUMBER",
"value": "Revision 2",
"modifiedAt": "2013-06-23T00:10:18Z",
"modifiedBy" : {
"name" : "Joe Smart",
"email" : "joe.smart#smartsheet.com"
}
}
]
}
You should be able to write a script that analyzes the revisions and lets you revert the value in a more automated fashion.

Schema.org TVEpisode entries for multi-source playback page

I'm expanding a static site with playable videos contextualized in a TV Series and I would like to know how to properly fill in the tags url and datePublished.
Currently, with only one embeddable source, the JSON-LD generated is:
<script type="application/ld+json">
{
"#context" : "http://schema.org",
"#type" : "TVEpisode",
"partOfTVSeries" : {
"#type" : "TVSeries",
"name" : "Name of the Show"
},
"keywords": "a,list,of,comma,separated,tags",
"partOfSeason" : {
"#type" : "TVSeason",
"seasonNumber" : "1"
},
"episodeNumber" : "1",
"image" : "absolute/path/to/video/image.jpg",
"url" : "permalink",
"review" : {
"#type" : "Review",
"author" : {
"#type" : "Person",
"name" : "Summary Author Name"
},
"reviewBody" : "Summary"
}
}
</script>
With only one embeddable source it was just a matter of using the template functions to retrieve the Permalink and the Date in which the video has been published.
But I don't know how to do it for multiple sources.
I tried to simply duplicate the whole block, simulating an iteration, changing the mentioned values but when testing with Structured Data Testing Tool, although no errors were reported, the second entry was ignored.
In JSON-LD, if you have multiple values for a property, you have to use an array as value instead of repeating the property.
You could provide multiple VideoObject items for the TVEpisode, by using TVEpisode’s associatedMedia/encoding property:
<script type="application/ld+json">
{
"#context": "http://schema.org",
"#type": "TVEpisode",
"associatedMedia": [
{
"#type": "VideoObject",
"name": "Source 1"
},
{
"#type": "VideoObject",
"name": "Source 2"
}
]
}
</script>
Now you can differentiate between the metadata for the TV episode and for its videos.

Multiple entities in schema.org

How do I nest one or multiple recipes in a NewsArticle or BlogPosting.
I tried this but Google's Structured Data Testing Tool throws an error complaining about recipe1 key. I'm not sure what to change recipe1 key to:
<script type="application/ld+json">
{
"#context" : "http://schema.org",
"#type" : "NewsArticle",
"author" : { "#type" : "Person",
"name" : "hgezim"
},
"dateModified" : "2016-09-21T06:25:35+00:00",
"datePublished" : "2016-09-21T06:25:35+00:00",
"headline" : "Chicken Papriak",
"mainEntityOfPage" : "http://localhost:8080/2016/09/21/chicken-papriak/",
"publisher" : { "#type" : "Organization",
"name" : "Dev Blog"
},
"recipe1": {
"#context": "http://schema.org",
"#type": "Recipe",
"author": "John Smith",
"cookTime": "PT1H",
"datePublished": "2009-05-08",
"description": "This classic banana bread recipe comes from my mom -- the walnuts add a nice texture and flavor to the banana bread.",
"image": "bananabread.jpg",
"recipeIngredient": [
"3 or 4 ripe bananas, smashed",
"1 egg",
"3/4 cup of sugar"
],
"interactionStatistic": {
"#type": "InteractionCounter",
"interactionType": "http://schema.org/Comment",
"userInteractionCount": "140"
},
"name": "Mom's World Famous Banana Bread",
"nutrition": {
"#type": "NutritionInformation",
"calories": "240 calories",
"fatContent": "9 grams fat"
},
"prepTime": "PT15M",
"recipeInstructions": "Preheat the oven to 350 degrees. Mix in the ingredients in a bowl. Add the flour last. Pour the mixture into a loaf pan and bake for one hour.",
"recipeYield": "1 loaf",
"suitableForDiet": "http://schema.org/LowFatDiet"
}
}
</script>
It depends on how the entities are related to each other. You have to use a property that is defined to convey this relation.
To look for a suitable property, check BlogPosting for properties that have Recipe or one of its parent types (CreativeWork, Thing) as expected value.
For example:
about could be used if the blog post is about this specific recipe (e.g., you describe how you liked it)
hasPart could be used if the recipe forms a part of the blog post
mentions could be used if you just reference this recipe in the blog post
…
Thanks #unor. I've used hasPart as follows:
<script type="application/ld+json">
{ "#context" : "http://schema.org",
"#type" : "NewsArticle",
"author" : { "#type" : "Person",
"name" : "hgezim"
},
"dateModified" : "2016-09-21T06:25:35+00:00",
"datePublished" : "2016-09-21T06:25:35+00:00",
"hasPart" : { "#context" : "http://schema.org",
"#type" : "Recipe",
"author" : "John Smith",
"cookTime" : "PT1H",
"datePublished" : "2009-05-08",
"description" : "This classic banana bread recipe comes from my mom -- the walnuts add a nice texture and flavor to the banana bread.",
"image" : "bananabread.jpg",
"interactionStatistic" : { "#type" : "InteractionCounter",
"interactionType" : "http://schema.org/Comment",
"userInteractionCount" : "140"
},
"name" : "Mom's World Famous Banana Bread",
"nutrition" : { "#type" : "NutritionInformation",
"calories" : "240 calories",
"fatContent" : "9 grams fat"
},
"prepTime" : "PT15M",
"recipeIngredient" : [ "3 or 4 ripe bananas, smashed",
"1 egg",
"3/4 cup of sugar"
],
"recipeInstructions" : "Preheat the oven to 350 degrees. Mix in the ingredients in a bowl. Add the flour last. Pour the mixture into a loaf pan and bake for one hour.",
"recipeYield" : "1 loaf",
"suitableForDiet" : "http://schema.org/LowFatDiet"
},
"headline" : "Chicken Papriak",
"mainEntityOfPage" : "http://localhost:8080/2016/09/21/chicken-papriak/",
"publisher" : { "#type" : "Organization",
"name" : "Dev Blog"
}
}
</script>
It validates as validates JSON-LD.

REST - Resource and Collection Representations

I have a confusion with the design of collection resources.
Let's say I have a user resource - represented as below.
http://www.example.com/users/{user-id}
user : {
id : "",
name : "",
age : "",
addresses : [
{
line1 : "",
line2 : "",
city : "",
state : "",
country : "",
zip : ""
}
]
}
Now, how should my users collection resource representation be? Should it be a list of user representations (as above)? Or can it be a subset of that like below:
http://www.example.com/users/
users : [
{
id : "",
name : "",
link : {
rel : "self",
href : "/users/{id}"
}
}
]
Should the collection resource representation include the complete representation of the containing resources or can it be a subset?
Media types define the rules on how you can convey information. Look at the specifications for Collection+JSON and HAL for examples of how to do what you are trying to do.
That falls entirely on what you want it to do. The great thing about REST APIs is that they are so flexible. You can represent data in any way (theoretically) that you want.
Personally, I would have an attribute that allows the user to specify a subset or style of representation. For instance /users/{userid}.json?output=simple or /users/{userid}.json?subset=raw
Something along those lines would also allow you to nest representations and fine tune what you want without sacrificing flexibility:
/users/{userid}.json?output=simple&subset=raw
The sky is the limit
I would make the list service fine grained by entertaining the
http://www.example.com/users?include=address|profile|foo|bar
Any delimiter (other than & and URL encoded) like , or - can be used instead of |. On the server side, check for those include attributes and render the JSON response accordingly.
There isn't really a standard for this. You have options:
1. List of links
Return a list of links to the collection item resources (i.e., the user IDs).
http://www.example.com/users/
users : [
"jsmith",
"mjones",
...
]
Note that these can actually be interpreted as relative URIs, which somewhat supports the "all resources should be accessible by following URIs from the root URI" ideal.
http://www.example.com/users/ + jsmith = http://www.example.com/users/jsmith
2. List of partial resources
Return a list of partial resources (users), allowing the caller to specify which fields to include. You might also have a default selection of fields in case the user doesn't supply any - the default might even be "include all fields."
http://www.example.com/users/?field=id&field=name&field=link
users : [
{
id : "jsmith",
name : "John Smith",
link : "www.google.com"
},
...
]
It can be subset but depends on the data. take a look at the below code.
{
"usersList": {
"users": [{
"firstName": "Venkatraman",
"lastName": "Ramamoorthy",
"age": 27,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [{
"type": "mobile",
"number": "+91-9999988888"
}, {
"type": "fax",
"number": "646 555-4567"
}]
}, {
"firstName": "John",
"lastName": "Smith",
"age": 25,
"address": {
"streetAddress": "21 2nd Street",
"city": "New York",
"state": "NY",
"postalCode": 10021
},
"phoneNumbers": [{
"type": "home",
"number": "212 555-1234"
}, {
"type": "fax",
"number": "646 555-4567"
}]
}]
}
}