The latest release of Schema.org (v3.3 August 2017) included enhancements proposed by The Tourism Structured Web Data Community Group.

Although fairly small, these enhancements have significantly improved the capability for describing Tourist Attractions and hopefully enabling more tourist discoveries like the one pictured here.

The TouristAttraction Type

The TouristAttraction type has been around, as a subtype of Place, from the earliest days back in 2011.  However it did not have any specific properties of its own or examples for its use.  For those interested in promoting and sharing data to help with tourism and the discovery of tourist attractions, the situation was a bit limiting.

As a result of the efforts by the group, TouristAttraction now has two properties — availableLanguage (A language someone may use with or at the item, service or place.) and touristType (Attraction suitable for type(s) of tourist. eg. Children, visitors from a particular country, etc.).   So now we can say, in data, for example that an attraction is suitable for Spanish & French speaking tourists who are interested in wine.

Application and Examples

At initial view the addition of a couple of general purpose properties does not seem much of an advancement.  However the set of examples, that the Group has provided, demonstrate the power and flexibility of this enhanced type for use with tourism.

The principle behind their approach, as demonstrated in the examples, is that most anything can be of interest to a tourist — a beach, mountain, costal highway, ancient building, work of art, war cemetery, winery, amusement park — the list is endless.  It was soon clear that it would not be practical to add tourist relevant properties to all such relevant types within Schema.org.

Multi-Typed Entities (MTEs)
The Multi-Type Entity is a powerful feature of Schema.org which has often caused confusion and has a bit of a reputation for being complex.  When describing a thing (an entity in data speak) Schema.org has the capability to indicate that it is of more than one type.

For example you could be describing a Book, with an author, subject, isbn, etc., and in order to represent a physical example of that book you can also say it is a Product with weight, width, purchaseDate, itemCondition, etc.  In Schema.org you simply achieve that by indicating in your mark-up that the thing you are describing is both a Book and a Product.

Utilising the MTE principle for tourism, you would firstly describe the thing itself, using the appropriate Schema.org Types (Mountain, Church, Beach, AmusementPark, etc.).  Having done that you then add the TouristAttraction type. 

In Microdata it would look like this:
  <div itemtype=“http://schema.org/Cemetery” itemscope>
    <link itemprop=“additionalType” href=“http://schema.org/TouristAttraction” />
    <meta itemprop=“name” content=“Villers–Bretonneux Australian National Memorial />

In JSON-LD:
<script type=“application/ld+json”>
{
“@context”: “http://schema.org/”,
 “@type”: [“Cemetery”,“TouristAttraction”],
 “name”: “Villers–Bretonneux Australian National Memorial”,

If there is no specific Schema.org type for the thing you are describing, you would just identify it as being a TouristAttraction, using all the properties inherited from Place to describe it as best as you can.

Following the ‘anything can be a tourist attraction principle’ it is perfectly possible for a Person to also be a TouristAttraction.  Take the human statue street performer who dresses up as the Statue of Liberty and stands in Times Square New York on most days (or at least seems to be there every time I visit).  

Using Schema.org he/she can be described as a Person with name, email, jobTitle (Human Statue of Liberty), etc., and in addition as a TouristAttraction.  Sharing this information in Schema.org on a page describing this performer would possibly increase their discoverability to those looking for tourist things in New York.

Public Access

In addition to the properties and examples for TouristAttraction, the Group also proposed a new publicAccess property.  It was felt that this had wider benefit than just for tourism and hence it was added to Place, and hence inherited by TouristAttraction.  publicAccess is a boolean property enabling you to state if a Place is or is not accessible to the public.  There is no assumed default value for this property if omitted from markup.

 

(Tourist image by Lain
Statue image by Bruce Crummy)

 

 

Comment   or   Contact us

There have been  discussions in Schema.org Github Issues about the way Organizations their offices, branches and other locations can be marked up.  (The trail is here: #1734)  It started with a question about why the property hasMap was available for a LocalBusiness but not for Organization.  The simple answer being that LocalBusiness inherits the hasMap property from Place, one of its super-types, and not from Organiszation, its other super-type.

As was commented in the thread…

there are plenty of organizations/corporations that have a head office which nobody would consider a LocalBusiness yet for which it would be handy to be able to express it can be found on a map.

The following discussion exposed a lack of clarity in the way to structure descriptions of Organizations and their locations, offices, branches , etc.  It is also clear that the current structure when applied correctly can deliver the functionality required.  This is not to recognise that the descriptions of terms and associated examples could not be improved, and may be helped by some tweaking to the current structure — the discussion continues!

To address that lack of clarity I thought it would be useful to share some examples here.

The LocalBusiness simple case
As a combination of Organization and Place, LocalBusiness gives you most anything you would need to describe a local shop, repair garage, café, etc.  Thus:
<script type=“application/ld+json”>
{
  “@context”: “http://schema.org”,
  “@type”: “LocalBusiness”,
“address”: {
    “@type”: “PostalAddress”,
    “addressLocality”: “Mexico Beach”,
    “addressRegion”: “FL”,
    “streetAddress”: “3102 Highway 98”
  },
  “description”: “A superb collection of fine gifts and clothing to accent your stay in Mexico Beach.”,
  “name”: “Beachwalk Beachwear & Giftware”,
  “telephone”: “850-648-4200”
}
</script>
There are plenty of other properties available, so for example if you have link to a map you could add:
“hasMap”: “https://www.google.co.uk/maps/place/Beachwalk/@29.94904,-85.4207543,17z”,

If you had other information about the business such as business numbers or tax identifiers you could add:
“vatID”: “1234567890abc”,

What about a group of LocalBusinesses
Also this is a fairly simple case. By using the parentOrganization & subOrganization properties (inherited from the Organiztion super-type) you can build a hierarchy of relationships as complex as you would ever need:
<script type=“application/ld+json”>
{
  “@context”: “http://schema.org”,
  “@type”: “LocalBusiness”,
  “@id”: “http://localshops.example.com/mainBranch”,
  “name”: “Localshops”,
  “subOrganization”: “http://localshops.example.com/cityBranch”
}
</script>
<script type=“application/ld+json”>
{
  “@context”: “http://schema.org”,
  “@type”: “LocalBusiness”,
  “@id”: “http://localshops.example.com/cityBranch”,
  “name”: “Localshops”,
  “parentOrganization”: “http://localshops.example.com/mainBranch”
}
</script>

Location and POS
There are a couple of properties inherited from Organization (location, hasPOS) which may help you link to things that might not be obvious local businesses — the warehouse location for your group of hardware stores, or the beach kiosk for your café for example.


Banks, Libraries, and Hotels
There are many local examples of larger organizations that appear on our high streets, for some of the more common ones there are ready made subtypes of LocalBusiness – BankOrCreditUnion, Library, Hotel, etc.  If you can’t find a suitable one, default to LocalBusiness.

This possibility sometimes causes some confusion.  For instance Wells Fargo, the global finance company, could no way be considered as a local business, however their branch in your local city can indeed be considered as one.  For example:
{
  “@context”: “http://schema.org”,
  “@type”: “BankOrCreditUnion”,
  “name”: “Wells Fargo – Smalltown Branch”,
  “parentOrganization”: “http://wellsfargo.com”
}

Governments, Global Corporations, Online Groups
Picking up on that confusion about non-LocalBusiness-ness, brings me to the prime use of the Organization type.  That prime use in my experience is to describe the legal entity, corporate organiation, cooperation group, government, international body, etc.  From a dictionary definition: “an organized group of people with a particular purpose, such as a business or government department.”

My approach to this would be to describe the organization first — name, description, email, foundingDate, leicode, logo, taxID, etc.  If it has a registered or main address, use the address property, if it has channels for specific contact methods etc, use contactPoint to describe areaServed, contactType etc.

Some of these organizations operate out of various locations — head offices, regional/country based main/local offices, factories, warehouses, distribution centres, research and development centres, laboratories, etc.  The list is a substantial one.  This is where the location property comes into play.

Each of those locations can then be described using a Place type or one of its subtypes…

<script type=“application/ld+json”>
{
  “@context”: “http://schema.org”,
  “@type”: “Organization”,
  “@id”: “http://global-corp.com”,
  “name”: “Global-Corp Company”,
  “location”:  [
   {
    “@type”: “Place”,
    “name”: “Global-Corp Company HQ”,
    “address”: “Future City Development, Main Street, Anytown, NY”,
    “hasMap”: “https://www.google.co.uk/maps/place/Anytown”
  },
  {
    “@type”: “Place”,
    “name”: “Global-Corp Company Research Laboratory”,
    “address”: “Lab1, Future Park, Anytown, NY”,
    “hasMap”: “https://www.google.co.uk/maps/place/Anytown”
  }
 ]
}
</script>

This is not a perfect solution, it would be nice to have specific subtypes of Place for Office, Factory, etc. or a placeType property on Place.  I am sure there will be continued discussion on this.   In the meantime what is already available goes a long way towards describing what is needed from Global Corporations to Local Cafés and everything in-between.

(Image: Simon)
Comment   or   Contact us

A theme of my last few years has been enabling the increased discoverability of Cultural Heritage resources by making the metadata about them more open and consumable.

Much of this work has been at the libraries end of the sector but I have always have had an eye on the broad Libraries, Archives, and Museums world, not forgetting Galleries of course.

Two years ago at the LODLAM Summit 2015 I ran a session to explore if it would be possible to duplicate in some way the efforts of the Schema Bib Extend W3C Community Group which proposed and introduced an extension and enhancements to the Schema.org vocabulary to improve its capability for describing bibliographic resources, but this time for archives physical, digital and web.

Interest was sufficient for me to setup and chair a new W3C Community Group, Schema Architypes. The main activity of the group has been the creation and discussion around a straw-man proposal for adding new types to the Schema.org vocabulary.

Not least the discussion has been focused on how the concepts from the world of archives (collections, fonds, etc.) can be represented by taking advantage of the many modelling patterns and terms that are already established in that generic vocabulary, and what few things would need to be added to expose archive metadata to aid discovery.

Coming up next week is LODLAM Summit 2017, where I have proposed a session to further the discussion on the proposal.

So why am I now suggesting that there maybe an opportunity for the discovery of archives and their resources?

In web terms for something to be discoverable it, or a description of it, needs to be visible on a web page somewhere. To take advantage of the current structured web data revolution, being driven by the search engines and their knowledge graphs they are building, those pages should contain structured metadata in the form of Schema.org markup.

Through initiatives such as ArchivesSpace and their application, and ArcLight it is clear that many in the world of archives have been focused on web based management, search, and delivery views of archives and the resources and references they hold and describe. As these are maturing it is clear that the need for visibility on the web is starting to be addressed.

So archives are now in a great place to grab the opportunity to take advantage of the benefits of Schema.org to aid discovery of their archives and what they contain. At least with these projects, they have the pages on which to embed that structured web data, once a consensus around the proposals from the Schema Architypes Group has formed.

I call out to those involved with the practical application of systems for the management, searching, and delivery of archives to at least take a look at the work of the group and possibly engage on a practical basis, exploring the potential and challenges for implementing Schema.org.

So if you want to understand more behind this opportunity, and how you might get involved, either join the W3C Group or contact me direct.

 

*Image acknowledgement to The Oberlin College Archives

Comment   or   Contact us