New GeoJSON and Schema.org alignments

[situx]

Closes #538 #540

@nicholascar
Open questions:

• sdo:location how does it relate to GeoSPARQL?
• sdo:contentLocation how does it relate to GeoSPARQL?
• sdo:hasMap how does it relate to GeoSPARQL?
• sdo:latitude and sdo:longitude could relate to properties for northing and easting. Should we define them? We only have functions for them now.
• geojson:bbox links to a list of coordinates, geo:hasBoundingBox links to a geometry. Are these properties related?
• geojson:coordinates is it equivalent to any of the literal properties such as geo:asWKT?

Once these questions are clarified:

• Waiting for PR [Alignments] Isolating alignments from main specification #527 to be merged since the alignments need to be documented in the new alignments document and not as a Annex

[nicholascar]

Also:

sdo:Place
sdo:spatial
sdo:containsPlace
sdo:containedInPlace
sdo:fromLocation
sdo:gameLocation
sdo:foudingLocation
sdo:homeLocation
sdo:jobLocation
sdo:locationCreated
so:pickupLocation

I use sdo:location, sdo:Place and a couple of other a fair bit, so I'll add to this PR with equivalencies soon.

Not all mappings are RDF-mapable, so in some cases, we may have written statements about conceptual mapping only, e.g. sdo:longitude & sdo:latitude → GeoSPARQL point geometry.

[nicholascar]

Since schema.org does indicate that some properties like sdo:homeLocation etc are indeed rdfs:subPropertyOf sdo:location then we don't need to align to them, just the parent - save us work.

Some of the predicates listed above, such as sdo:locationCreated don't indicate this, so we need to work out if they should, and issue a PR to schema.org, or if they shouldn't and what we do about them from a GeoSPARQL perspective.