I went through and fixed many examples, one of which was actually causing my RDFa processor to hang! Everything else should be non-controversial, but there are some issues that indicate properties might be misnamed.
There are many more markup issues, and it would be great if new examples passed some form of validation before being incorporated. These were identified using a command-line tool in the linter.
Fix seriously broken URL in games-6 example. (This actually caused my…
… URI validation regexp to hang!)
Broken RDFa markup on games-1 caused cheat to be associated with Vide…
…oObject, not VideoGame.
Wrong property usage in game-3.
Games-6 minAge doesn't parse as Number due to added space, which is u…
…nnecessary in markup.
music-2 example used "type" instead of "@type".
music-3 example used obsolete namedPosition instead of roleName.
music-5 used releaseEvent instead of releasedEvent. Perhaps the prope…
…rty is misnamed?
bib-5 microdata and RDFa should use @datetime property instead of @co…
…ntent to properly parse the Duration value.
Bad date format in games-7 example. Also, note that gameLocation is n…
…ot a property of VideoGameSeries.
Book example had "598 Pages" as the value of numberOfPages. Moved 598…
… to a span and removed " Pages" from JSON-LD.
BusReservation example used undefined "operatingCompany" instead of "…
BuyAction example used "location" with Amazon as a "Product". Changed…
… to "seller" and "Organization".
@danbri if there's a better place for this PR to go, let me know. I may continue updating the PR with new example fixes until then.
smart! 👍 @samuelgoto
Just to say a huge thanks for doing these. There's a bit of administrivia to do first before integrating but ... thanks - much appreciated :)
I think that first one should be %20 not just % ...?
line 735: Monopoly%Game">
Ok I've merged in #260 ... can we close this version?
I made the %20 tweak afterwards.
Suggestions for better workflow welcomed - would you prefer I ask the original pull request to be reconfigured to another branch? in this case I wanted it against sdo-stantz rather than master branch, and it seemed easier just to make another quick pull request. I couldn't see a way to change this one myself.
You cannot change the target branch once the pull request is created, you have to create a new one, as inconvenient as it is...
What if you set the default branch and adjusted it accordingly after each release? https://help.github.com/articles/setting-the-default-branch/ - pull requests will be created against that branch by default.
Thanks @scor just what I was looking for! :)
Related - I've updated #53 with a link to the results of re-running this linter against today's version of sdo-stantz: https://gist.github.com/danbri/c5fef76dcf89bc23bdb6
After investigating I'm pretty sure releasedEvent was intended - so I'll close the issue.