This is getting really complex. I would like to have a discussion and
involvement from application builders first.

Distance, like other quantities, should be specifiable in a simple and easy
fashion most of the times.

Guha

On Fri, Oct 2, 2015 at 2:25 PM, Martin Hepp [email protected]
wrote:

This pull request addresses #830

#830.

You can view, comment on, or merge this pull request online at:

#832
Commit Summary

• added DistanceSpecification

File Changes

• M data/schema.rdfa
  https://github.com/schemaorg/schemaorg/pull/832/files#diff-0 (23)

Patch Links:

• https://github.com/schemaorg/schemaorg/pull/832.patch
• https://github.com/schemaorg/schemaorg/pull/832.diff

—
Reply to this email directly or view it on GitHub
#832.

I've made an example based on the file and if I interpreted it correctly I don't think it's that complex at all really. I guess the complexity depends more on whether I understood the pull request properly, because if so, I don't see much of an issue with adding @mfhepp's proposal:

<script type="application/ld+json">
{
    "@type":"Hotel",
    "name":"Hilton Amsterdam Airport Schiphol",
    "distanceInformation":{
        "@type":"DistanceSpecification",
        "value":"500",
        "unitCode":"MTR",
        "unitText":"metres",
        "destination":{
            "@type":"Airport",
            "name":"Schiphol"
        }
    }
}
</script>

@jvandriel You got it exactly right. This is what I had in mind. You could augment it by a sameAs to a Wikipedia URL, in particular for airports etc.

@rvguha An alternative, simpler approach is a single nearPlace property with a domain and range of Place. If the second place has geo-coordinates, the Euclidian distance can be computed (approximately) with ease.

So it is more a question of which kind of data is better for the search engines:

a) A distance information provided by the Web site (as proposed) or
b) Just a pointer to the noteworthy places for which distance information should be reconstructed from other sources (geocoding, route planning, ..)

It would be nice to have a decision shortly.

I would prefer a symmetric construction.

guha

On Wed, Oct 7, 2015 at 2:11 AM, jvandriel [email protected] wrote:

I've made an example based on the file and if I interpreted the it
correctly I don't think it's that complex at all really. So I guess the
complexity more depends on whether I understood the pull request properly,
because if so, I don't see much of an issue with this:

<script type="application/ld+json"> { "@type":"Hotel", "name":"Hilton Amsterdam Airport Schiphol", "distanceInformation":{ "@type":"DistanceSpecification", "value":"500", "untiCode":"MTR", "untiText":"metres", "destination":{ "@type":"Airport", "name":"Schiphol" } } } </script>

—
Reply to this email directly or view it on GitHub
#832 (comment).

"I would prefer a symmetric construction."

I fear I don't understand what you mean with this @rvguha, would you mind explaining that?
(sorry I don't understand all the lingo - still learning)

@rvguha formally, both of my proposed approaches are symmetric. But if you look at the relevant subsets of all data, they might depend on the direction.

For example, twenty hotels will indicate their distance to the nearest airport.
But the airport will never link to the hotels.

A nearPlace property would come closer to your goal, but again, if hotel 1 says it is 70 miles to a certain airport, one would not always agree that from the perspective of the airport, that hotel is "near".

Even if we renamed the property to featuredPlace, it would not really be symmetrical - for any hotel, the nearest airport is a featuredPlace. But not every hotel in the 100 miles range of an airport is of any particular value for that airport.

Look at

http://en.hrs.com/germany/munich/

They indicate the distance to the nearest airport, train station, and city center for each hotel, and that is very relevant information.

I think many (if not most) travel/booking sites have similar data:

• booking.com: http://bit.ly/1OtDkmY
• accorhotels.com: http://bit.ly/1K4aktY

And as these examples illustrate, this info isn't always referring to something that's all that easy to define as a schema.org/Place with an address or geo data, like 'city center' or 'highway exit'. So from that POV something definitely could be said for @mfhepp's proposal.

But I also see the positives of a simpler solution. So I guess it's like Martin said, "it is more a question of which kind of data is better for the search engines", although, if most of these types of sites publish this type of data, it seems to be an indication consumers are interested in it as well.

What I mean is that a statement of the form 'the distance between X & Y is
Z' should be equivalent to 'the distance from X to Y is Z' which should be
equivalent to 'the distance from Y to X is Z'. The representation for all 3
should be the same.

Its not about who links to whom.

guha

On Sun, Oct 11, 2015 at 2:02 PM, jvandriel [email protected] wrote:

"I would prefer a symmetric construction."

I fear I don't understand what you mean with this @rvguha
https://github.com/rvguha, would you mind explaining that?
(sorry, I don't understand all the lingo - still learning)

—
Reply to this email directly or view it on GitHub
#832 (comment).

Both of my proposed patterns are symmetrical in terms of the distance between the two places. They are not symmetrical in the relevance of the second place for the first place in the statement.

Does this meet your requirement?

Martin

On 13 Oct 2015, at 21:07, R.V.Guha [email protected] wrote:

What I mean is that a statement of the form 'the distance between X & Y is
Z' should be equivalent to 'the distance from X to Y is Z' which should be
equivalent to 'the distance from Y to X is Z'. The representation for all 3
should be the same.

Its not about who links to whom.

guha

On Sun, Oct 11, 2015 at 2:02 PM, jvandriel [email protected] wrote:

"I would prefer a symmetric construction."

I fear I don't understand what you mean with this @rvguha
https://github.com/rvguha, would you mind explaining that?
(sorry, I don't understand all the lingo - still learning)

—
Reply to this email directly or view it on GitHub
#832 (comment).

—
Reply to this email directly or view it on GitHub.

To be symmetrical, it would need to look more like:

<script type="application/ld+json">
{
    "@type":"DistanceSpecification",
    "value":"500",
    "unitCode":"MTR",
    "unitText":"metres",
    "location": [
        {
            "@type":"Hotel",
            "name":"Hilton Amsterdam Airport Schiphol"
        }, 
       {
            "@type":"Airport",
            "name":"Schiphol"
       }
   ]
}
</script>

JSON-LD makes it easy to express the graph from any node, but RDFa and microdata make it harder to get the semantics right while still organizing the page the way people want to read it.

I like vicki's proposal. Very clean and simple.

guha

On Wed, Oct 14, 2015 at 8:35 AM, vholland [email protected] wrote:

To be symmetrical, it would need to look more like:

<script type="application/ld+json"> { "@type":"DistanceSpecification", "value":"500", "unitCode":"MTR", "unitText":"metres", "location": [ { "@type":"Hotel", "name":"Hilton Amsterdam Airport Schiphol" }, { "@type":"Airport", "name":"Schiphol" } ] } </script>

JSON-LD makes it easy to express the graph from any node, but RDFa and
microdata make it harder to get the semantics right while still organizing
the page the way people want to read it.

—
Reply to this email directly or view it on GitHub
#832 (comment).

Yes, but note that most of this information is provided on the page of one of the places, e.g. the hotel.

For Vicki's approach to work, we need inverse properties, which are not available in Microdata and difficult in practive in JSON-LD.

This is why I designed it in a way that works from one place to another place.

Martin

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 14 Oct 2015, at 11:47, R.V.Guha [email protected] wrote:

I like vicki's proposal. Very clean and simple.

guha

On Wed, Oct 14, 2015 at 8:35 AM, vholland [email protected] wrote:

To be symmetrical, it would need to look more like:

<script type="application/ld+json"> { "@type":"DistanceSpecification", "value":"500", "unitCode":"MTR", "unitText":"metres", "location": [ { "@type":"Hotel", "name":"Hilton Amsterdam Airport Schiphol" }, { "@type":"Airport", "name":"Schiphol" } ] } </script>

JSON-LD makes it easy to express the graph from any node, but RDFa and
microdata make it harder to get the semantics right while still organizing
the page the way people want to read it.

—
Reply to this email directly or view it on GitHub
#832 (comment).

—
Reply to this email directly or view it on GitHub.

The fact that only one the place's web pages provides the data is not super
relevant here.

There are a lot of uses for Distance specification, aside from hotels. So,
lets go for a cleaner representation.

guha

On Wed, Oct 14, 2015 at 9:22 AM, Martin Hepp [email protected]
wrote:

Yes, but note that most of this information is provided on the page of one
of the places, e.g. the hotel.

For Vicki's approach to work, we need inverse properties, which are not
available in Microdata and difficult in practive in JSON-LD.

This is why I designed it in a way that works from one place to another
place.

Martin

---

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 14 Oct 2015, at 11:47, R.V.Guha [email protected] wrote:

I like vicki's proposal. Very clean and simple.

guha

On Wed, Oct 14, 2015 at 8:35 AM, vholland [email protected]
wrote:

To be symmetrical, it would need to look more like:

<script type="application/ld+json"> { "@type":"DistanceSpecification", "value":"500", "unitCode":"MTR", "unitText":"metres", "location": [ { "@type":"Hotel", "name":"Hilton Amsterdam Airport Schiphol" }, { "@type":"Airport", "name":"Schiphol" } ] } </script>

JSON-LD makes it easy to express the graph from any node, but RDFa and
microdata make it harder to get the semantics right while still
organizing
the page the way people want to read it.

—
Reply to this email directly or view it on GitHub
<
https://github.com/schemaorg/schemaorg/pull/832#issuecomment-148087982>.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#832 (comment).

Guha:
Actually, I don't understand your argument.

The data will typically be provided by one Web page, most likely describing one of the places. If you want Vicki's pattern to be populated, you either need to nest the entire Place entity within the DistanceSpecification entity, or use inverse properties.

This makes it terribly complicated for a hotel to publish such data.

Now, what may work is a combination of both: Provide a symmetrical pattern (with two location links from the DistanceSpecification) and a unidirectional one (with one link like "near" from the Place to the DistanceSpecification and one location link to the second place.

Like so:

Symmetrical pattern:

Pattern from the perspective of one Place

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 14 Oct 2015, at 12:26, R.V.Guha [email protected] wrote:

The fact that only one the place's web pages provides the data is not super
relevant here.

There are a lot of uses for Distance specification, aside from hotels. So,
lets go for a cleaner representation.

guha

On Wed, Oct 14, 2015 at 9:22 AM, Martin Hepp [email protected]
wrote:

Yes, but note that most of this information is provided on the page of one
of the places, e.g. the hotel.

For Vicki's approach to work, we need inverse properties, which are not
available in Microdata and difficult in practive in JSON-LD.

This is why I designed it in a way that works from one place to another
place.

Martin

---

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 14 Oct 2015, at 11:47, R.V.Guha [email protected] wrote:

I like vicki's proposal. Very clean and simple.

guha

On Wed, Oct 14, 2015 at 8:35 AM, vholland [email protected]
wrote:

To be symmetrical, it would need to look more like:

<script type="application/ld+json"> { "@type":"DistanceSpecification", "value":"500", "unitCode":"MTR", "unitText":"metres", "location": [ { "@type":"Hotel", "name":"Hilton Amsterdam Airport Schiphol" }, { "@type":"Airport", "name":"Schiphol" } ] } </script>

JSON-LD makes it easy to express the graph from any node, but RDFa and
microdata make it harder to get the semantics right while still
organizing
the page the way people want to read it.

—
Reply to this email directly or view it on GitHub
<
https://github.com/schemaorg/schemaorg/pull/832#issuecomment-148087982>.

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#832 (comment).

—
Reply to this email directly or view it on GitHub.

Side-node:

On 14 Oct 2015, at 12:26, R.V.Guha [email protected] wrote:
There are a lot of uses for Distance specification, aside from hotels. So,
lets go for a cleaner representation.

This is not hotel-specific. My concern apply whenever the distance is on a page that describes one of the places as a major entity.

Martin

Then, lets drop it out of the hotels proposal and wait till some
application needs it.

guha

On Wed, Oct 14, 2015 at 9:35 AM, Martin Hepp [email protected]
wrote:

Side-node:

On 14 Oct 2015, at 12:26, R.V.Guha [email protected] wrote:
There are a lot of uses for Distance specification, aside from hotels.
So,
lets go for a cleaner representation.

This is not hotel-specific. My concern apply whenever the distance is on a
page that describes one of the places as a major entity.

Martin

—
Reply to this email directly or view it on GitHub
#832 (comment).

Wouldn't something like this satisfy the Symmetrical pattern and the how it appears on a page, and in RDFa, needs?

<div vocab="http://schema.org/">
 Hotel: 
 <span typeof="Hotel" resource="#hot1" >
    <h1 property="name">Hilton Amsterdam Airport Schiphol</h1>
 </span>
 Distance from <a typeof="Airport" href="http://www.schiphol.nl/">Schipol Airport</a>
 <span typeof="DistanceSpecification">
   <span property="value">500</span>
   <span property="unitText">metres</span>
   <meta property="unitCode" content="MTR"/>
   <link property="location" href="#hot1"/>   
   <link property="location" href="http://www.schiphol.nl/"/>   
 </span>

@RichardWallis Yes, of course, using identifier-based linking or inverse properties, @vholland 's proposal can be used. But it is then very difficult for adopters. In general, I think the vocabulary should be designed in a way that identifier-based linking in not needed, at least for very popular use-cases.

"Then, lets drop it out of the hotels proposal and wait till some application needs it."

As an SEO I've consulted a considerable amount of Holland's (and also some international) booking/hotel/vacation-oriented corporations over the years and one of the themes that has repeatedly come back to the table is that the folks working for those types of businesses/corporations are often 'flabbergasted' schema.org offers almost no means to descibe tourist information 'near' a Place (through properties at least).

Which can be another Place, but often also consists out of simple text values like 'city center', 'bus stop', 'taxi point', etc. + a (estimated) distance in 'meters', 'walking/driving time', etc. Data that's extremely relevant for folks planning to travel. Making it data booking/hotel/vacation-oriented sites already publish because not publishing it would hurt their business. Thus making it a form of structured data that will stand a decent chance for a high adoption rate.

Now what I don't understand about the quoted remark is that, if this data is so readably available because it fulfils consumer needs, isn't it than very likely applications will start using this data the moment it is available as structured data - why keep it out of the hotels proposal until some application asks for it?

Unless a distanceInformation/near/abcde property (+ DistanceSpecification) would be added to both Place and Organization that is, because I definitely can imagine it being used for those as well.

On Wed, Oct 14, 2015 at 2:55 PM, jvandriel [email protected] wrote:

"Then, lets drop it out of the hotels proposal and wait till some
application needs it."

Now what I don't understand about the quoted remark is that, if this data
is so readably available because it fulfils consumer needs, isn't it than
very likely applications will start using this data the moment it is
available as structured data?

Great. Why don't we hear from these these app developers first and then
decide what we should do.

—
Reply to this email directly or view it on GitHub
#832 (comment).

Sorry folks only just found this big (and rather grumpy-sounding) thread.

I am disappointed that none of you have yet mentioned:

• http://schema.org/distance "The distance travelled, e.g. exercising or travelling." (from: ExerciseAction TravelAction; to: Distance)
• http://schema.org/Distance (a Quantity), "Properties that take Distances as values are of the form ' '. E.g., '7 ft'."
• note that Distance is also used on depth/height/width values in other (smaller!) contexts e.g. VisualArtwork. Are we happy with this design?

Expressing distances in a simple way does seem useful. Let's take care that whatever we do does not leave these related constructions dangling without explaining how these idioms related to each other.

I suspect it may also be time to take a fresh look at our units/measurements construction ( '7 ft' etc.) before building upon it further. e.g. is '7 m' a representation of 7 miles, or 7 metric metres?

• regarding symmetry, are we talking about (approximately linear) distance on the map? i.e. purely geometric distance, or bound to a road route, or phrased in terms of travel time? is linear distance what we see on most sites? travel times are often asymmetrical.
• given that TravelAction and ExerciseAction (also TransferAction) use http://schema.org/fromLocation and http://schema.org/toLocation can we consider re-using those properties (which are subproperties of 'location')?
• let's consider our existing http://schema.org/Reservation subtypes for travel (bus, taxi, train - although they seem to have no distinctive properties yet per subtype). These are also have associated types such as http://schema.org/Flight which has a symmetrical representation of from vs to, using several properties: arrival{_Airport, *Gate, *Time) and departure{_Airport, *Gate, *Time), as well as a flightDistance property ("The distance of the flight.").

Other existing mentions of distance that we should review before adding to the chaos:

• https://schema.org/TaxiService ("A service for a vehicle for hire with a driver for local travel. Fares are usually calculated based on distance traveled.")
• https://schema.org/mileageFromOdometer ("The total distance travelled by the particular vehicle since its initial production, as read from its odometer. Typical unit code(s): KMT for kilometers, SMI for statute miles")

After the extensive cleanup changes we've been making recently I don't want to casually reintroduce more fragmentation by making additions without even considering such overlaps. We cannot of course always come up with a grand unification across all areas of schema.org; however we should at least make a list of such potential overlaps and decide explicitly whether or not we choose to attempt various kinds of integration.

"I am disappointed that none of you have yet mentioned"

Heck, good you mention these @danbri, I wasn't even aware these existed. I guess with some modification they could easily be used instead of distanceInformation and schema.org/DistanceSpecification.

"is linear distance what we see on most sites? travel times are often asymmetrical."

For sites like I mentioned many distances involve either estimated distances or travel time. Although they also often express 'near to' without any actual distance value.

"can we consider re-using those properties (which are subproperties of 'location')?"

Seems reasonable to me.

Good point Dan. There are 2 distinct points:

1. Representation of quantities --- a unit of measure + a scalar value. 10
   miles, 20 lbs, etc.
2. Association of a quantity to one (or more) objects. Height of an object,
   distance between two places, etc.

We really need to keep these separate.

guha

Aren't locations of X and Y a simple basis to calculate their distance?

The purpose of the proposal is to provide a mechanism that

1. allows indicating a set of particularly relevant places in the vicinity of a place (the choice will often not just depend on the geographical distance ; think of a ski hotel in Austria pointing to Munich and Innsbruck airports as the two closes flight destinations),
2. indicate distance information with having the geo-position of the referenced place (not every hotel has the latitude and longitude of the relevant places),
3. use various units of measurement, spatial (miles, kilometers, meters, foot) and temporal (minutes / hours) ones, and reference information (e.g. on foot, by car, by train),
4. allow but not require the use of sameAs to point to an official identifier for the referenced entity.

A much simpler approach would simply define a nearBy property with a domain and range of Place, which just addresses #1 from the list above, and to defer all tasks related to #2 - #4 to the processing agent (e.g. based on entity consolidation techniques, computation of distances and travel times, unit conversion).

I can live with both directions, but let's please

• agree upon one of the two alternatives and
• keep the perspective of Web developers and existing hotel markup in mind.

Best

Martin

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 26 Oct 2015, at 18:39, Andreas Kuckartz [email protected] wrote:

Aren't locations of X and Y a simple basis to calculate their distance?

—
Reply to this email directly or view it on GitHub.

Martin,

What are you referring to by 'existing hotel markup'?

guha

On Tue, Oct 27, 2015 at 5:40 AM, Martin Hepp [email protected]
wrote:

The purpose of the proposal is to provide a mechanism that

1. allows indicating a set of particularly relevant places in the vicinity
   of a place (the choice will often not just depend on the geographical
   distance ; think of a ski hotel in Austria pointing to Munich and Innsbruck
   airports as the two closes flight destinations),
2. indicate distance information with having the geo-position of the
   referenced place (not every hotel has the latitude and longitude of the
   relevant places),
3. use various units of measurement, spatial (miles, kilometers, meters,
   foot) and temporal (minutes / hours) ones, and reference information (e.g.
   on foot, by car, by train),
4. allow but not require the use of sameAs to point to an official
   identifier for the referenced entity.

A much simpler approach would simply define a nearBy property with a
domain and range of Place, which just addresses #1 from the list above, and
to defer all tasks related to #2 - #4 to the processing agent (e.g. based
on entity consolidation techniques, computation of distances and travel
times, unit conversion).

I can live with both directions, but let's please

• agree upon one of the two alternatives and
• keep the perspective of Web developers and existing hotel markup in mind.

Best

Martin

---

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 26 Oct 2015, at 18:39, Andreas Kuckartz [email protected]
wrote:

Aren't locations of X and Y a simple basis to calculate their distance?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#832 (comment).

html ;)

martin hepp
www: http://www.heppnetz.de/
email: [email protected]

On 27.10.2015, at 15:08, R.V.Guha [email protected] wrote:

Martin,

What are you referring to by 'existing hotel markup'?

guha

On Tue, Oct 27, 2015 at 5:40 AM, Martin Hepp [email protected]
wrote:

The purpose of the proposal is to provide a mechanism that

1. allows indicating a set of particularly relevant places in the vicinity
   of a place (the choice will often not just depend on the geographical
   distance ; think of a ski hotel in Austria pointing to Munich and Innsbruck
   airports as the two closes flight destinations),
2. indicate distance information with having the geo-position of the
   referenced place (not every hotel has the latitude and longitude of the
   relevant places),
3. use various units of measurement, spatial (miles, kilometers, meters,
   foot) and temporal (minutes / hours) ones, and reference information (e.g.
   on foot, by car, by train),
4. allow but not require the use of sameAs to point to an official
   identifier for the referenced entity.

A much simpler approach would simply define a nearBy property with a
domain and range of Place, which just addresses #1 from the list above, and
to defer all tasks related to #2 - #4 to the processing agent (e.g. based
on entity consolidation techniques, computation of distances and travel
times, unit conversion).

I can live with both directions, but let's please

• agree upon one of the two alternatives and
• keep the perspective of Web developers and existing hotel markup in mind.

Best

Martin

---

martin hepp http://www.heppnetz.de
[email protected] @mfhepp

On 26 Oct 2015, at 18:39, Andreas Kuckartz [email protected]
wrote:

Aren't locations of X and Y a simple basis to calculate their distance?

—
Reply to this email directly or view it on GitHub.

—
Reply to this email directly or view it on GitHub
#832 (comment).

—
Reply to this email directly or view it on GitHub.

I'm going to close this pull request, and invite the creation of an issue that states the problem that this proposal solves. In general giant discussions in a pull request page are a sign that we've got a solution without consensus on the problem.