New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

hasMap can be applied to LocalBusiness, but not to Organization #1734

Open
e-orlov opened this Issue Sep 6, 2017 · 20 comments

Comments

Projects
None yet
10 participants
@e-orlov

e-orlov commented Sep 6, 2017

As in subject, is it not a bit against the logic, that LocalBusiness, being a subtype of Organization may have hasMap, but not the Organization, being a parental type of LocalBusiness.

According to this works the testing tool too: on testing of Organization with hasMap an error is fired, on testing LocalBusiness with hasMap the markup passes the test.

@RichardWallis

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Sep 6, 2017

Contributor

hasMap is available on LocalBusiness as LocalBusiness is a subtype of Place, as well as Organization.

Which is logical as you would expect to find a place on a map whereas not necessarily an organization.

Contributor

RichardWallis commented Sep 6, 2017

hasMap is available on LocalBusiness as LocalBusiness is a subtype of Place, as well as Organization.

Which is logical as you would expect to find a place on a map whereas not necessarily an organization.

@jvandriel

This comment has been minimized.

Show comment
Hide comment
@jvandriel

jvandriel Sep 6, 2017

I have to say I agree with @e-orlov on this one. After all, 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.

Now of course one could create an MTE for this like ["Organization","Place"] but to me this feels cumbersome and an over-complication of things and therefor I'm in favor of expanding hasMap's domain to Organization.

jvandriel commented Sep 6, 2017

I have to say I agree with @e-orlov on this one. After all, 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.

Now of course one could create an MTE for this like ["Organization","Place"] but to me this feels cumbersome and an over-complication of things and therefor I'm in favor of expanding hasMap's domain to Organization.

@DDeering

This comment has been minimized.

Show comment
Hide comment
@DDeering

DDeering Sep 7, 2017

I also have to second that. Many organizations can't be labeled "local businesses" but they still indeed have an office location, hours of operation, and so on. I tend to think that all properties of LocalBusiness should also be a part of Organization so that each organization/corporation could utilize the properties that fit their particular situation.

DDeering commented Sep 7, 2017

I also have to second that. Many organizations can't be labeled "local businesses" but they still indeed have an office location, hours of operation, and so on. I tend to think that all properties of LocalBusiness should also be a part of Organization so that each organization/corporation could utilize the properties that fit their particular situation.

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Sep 7, 2017

Contributor
Contributor

mfhepp commented Sep 7, 2017

@RichardWallis

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Sep 7, 2017

Contributor

I tend with Martin to contradict also.

There are many organizations (an organized group of people with a particular purpose, such as a business or government department.) that have no specific location.

I think the real problem is the semantics being applied to the name of the LocalBusiness type. which brings to mind a local hardware store or ice cream shop. The head office (branch) of a global organization is an equally valid use of LocalBusiness as for a small town branch of a national bank.

I would be in favour of tweaking the description of LocalBusiness, and maybe adding some examples, to indicate its use to describe a place specific organization. In addition Martin's suggestion of hasOffice makes sense.

Contributor

RichardWallis commented Sep 7, 2017

I tend with Martin to contradict also.

There are many organizations (an organized group of people with a particular purpose, such as a business or government department.) that have no specific location.

I think the real problem is the semantics being applied to the name of the LocalBusiness type. which brings to mind a local hardware store or ice cream shop. The head office (branch) of a global organization is an equally valid use of LocalBusiness as for a small town branch of a national bank.

I would be in favour of tweaking the description of LocalBusiness, and maybe adding some examples, to indicate its use to describe a place specific organization. In addition Martin's suggestion of hasOffice makes sense.

@jvandriel

This comment has been minimized.

Show comment
Hide comment
@jvandriel

jvandriel Sep 7, 2017

The combination of adding a hasOffice to Organization and tweaking the description of LocalBusiness sounds good to me.

How about changing "A particular physical business or branch of an organization." into "A particular physical business or branch or head office of an organization."

jvandriel commented Sep 7, 2017

The combination of adding a hasOffice to Organization and tweaking the description of LocalBusiness sounds good to me.

How about changing "A particular physical business or branch of an organization." into "A particular physical business or branch or head office of an organization."

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Sep 7, 2017

Contributor

What is the difference between the proposed hasOffice and the existing location property? Are we trying to differentiate headquarters or a main office?

Contributor

vholland commented Sep 7, 2017

What is the difference between the proposed hasOffice and the existing location property? Are we trying to differentiate headquarters or a main office?

@DDeering

This comment has been minimized.

Show comment
Hide comment
@DDeering

DDeering Sep 7, 2017

I'd be in favor of changing the description of LocalBusiness so that it applies to organizations/corporations that have a physical location if the majority here would like that. But I could also foresee a problem with users getting confused about the use of LocalBusiness if their business serves a national or international customer base and customers do not actually come to their location to do business.

So while I understand and always try to defer to Martin and Richard, my thought is that it would be easier to simply copy the properties of LocalBusiness into Organization and that would address multiple problems and deficiencies of Organization.

DDeering commented Sep 7, 2017

I'd be in favor of changing the description of LocalBusiness so that it applies to organizations/corporations that have a physical location if the majority here would like that. But I could also foresee a problem with users getting confused about the use of LocalBusiness if their business serves a national or international customer base and customers do not actually come to their location to do business.

So while I understand and always try to defer to Martin and Richard, my thought is that it would be easier to simply copy the properties of LocalBusiness into Organization and that would address multiple problems and deficiencies of Organization.

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Sep 9, 2017

Contributor
Contributor

rvguha commented Sep 9, 2017

@RichardWallis

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Sep 11, 2017

Contributor

@rvguha That confusion is what I was referring to with "the real problem is the semantics being applied to the name of the LocalBusiness type".

From my initial involvement with SDO I have understood an organization (an organized group of people with a particular purpose, such as a business or government department.) to be not necessarily associated with a physical location, but if it was it would have an address property. In most cases I would expect this to be the head office, or registered, address.

If an organisation has multiple locations (a shopping chain, bank, etc.) there are currently two approaches that can be used: a) location or hasPOS linking to a Place (or LocalBusiness) description or; b) department or subOrganisation properties linking to LocalBusiness descriptions.

We also have the use of LocalBusiness type on its own which is ideal for describing small chains, or individual businesses and their premises such as cafés, repair shops, etc.

In principle there is no difference in the descriptive requirements between the 2nd branch of a local coffee shop and the local branch of a global bank, or the London office of Amazon.com. However the use of 'local' in the type name does cause some semantic confusion/problems. Although Amazon's London office could be considered as a place where they carry on business focused in the London/UK locality, no way could they be considered a local business.

Over the years with varying levels of success I have encouraged implementers to interpret LocalBusiness to mean the local[ized] presence of an organization of any type, size, or global presence.

Threads such as this (and the often failure of such encouragement) lead me to believe that we might make things simpler [for implementers] if we interposed a new type between Organization and LocalBusiness. It would be a subtype of both Organization and Place and named something like BusinessLocation and introduce a new property (locationType ?) to enable the definition of attributes such has "Head Office", "Distribution Centre", "Warehouse", etc.

An alternative to this, as @DDeering suggests, would be to add all that capability to Organization effectively making it another subtype of Place. I believe this blurring between an organisation and its physical location(s) would be a wrong move. For example attributing a statement to an organization (government, W3C, Amazon.com, Google, Amazon.com, Alphabet Inc, etc.) could easily be wrong if the description of the organisation is confined to a single location.

I believe most folks get the difference between an organisation and the place(s) from where it carries out its activities, hence my BusinessLocation suggestion above.

Contributor

RichardWallis commented Sep 11, 2017

@rvguha That confusion is what I was referring to with "the real problem is the semantics being applied to the name of the LocalBusiness type".

From my initial involvement with SDO I have understood an organization (an organized group of people with a particular purpose, such as a business or government department.) to be not necessarily associated with a physical location, but if it was it would have an address property. In most cases I would expect this to be the head office, or registered, address.

If an organisation has multiple locations (a shopping chain, bank, etc.) there are currently two approaches that can be used: a) location or hasPOS linking to a Place (or LocalBusiness) description or; b) department or subOrganisation properties linking to LocalBusiness descriptions.

We also have the use of LocalBusiness type on its own which is ideal for describing small chains, or individual businesses and their premises such as cafés, repair shops, etc.

In principle there is no difference in the descriptive requirements between the 2nd branch of a local coffee shop and the local branch of a global bank, or the London office of Amazon.com. However the use of 'local' in the type name does cause some semantic confusion/problems. Although Amazon's London office could be considered as a place where they carry on business focused in the London/UK locality, no way could they be considered a local business.

Over the years with varying levels of success I have encouraged implementers to interpret LocalBusiness to mean the local[ized] presence of an organization of any type, size, or global presence.

Threads such as this (and the often failure of such encouragement) lead me to believe that we might make things simpler [for implementers] if we interposed a new type between Organization and LocalBusiness. It would be a subtype of both Organization and Place and named something like BusinessLocation and introduce a new property (locationType ?) to enable the definition of attributes such has "Head Office", "Distribution Centre", "Warehouse", etc.

An alternative to this, as @DDeering suggests, would be to add all that capability to Organization effectively making it another subtype of Place. I believe this blurring between an organisation and its physical location(s) would be a wrong move. For example attributing a statement to an organization (government, W3C, Amazon.com, Google, Amazon.com, Alphabet Inc, etc.) could easily be wrong if the description of the organisation is confined to a single location.

I believe most folks get the difference between an organisation and the place(s) from where it carries out its activities, hence my BusinessLocation suggestion above.

@rtroncy

This comment has been minimized.

Show comment
Hide comment
@rtroncy

rtroncy Sep 11, 2017

I fully agree with the concerns made by @RichardWallis if SDO was mixing location and organizations. A different perspective comes from the Natural Language Processing research field where we teach machines to extract and disambiguate named entities of various types. One common mistake of all systems, is the proper distinction between the ORG and the LOC types, precisely because the way we use those entities in common language is confusing. Nevertheless, this distinction is important (challenges are even made to properly tackle this difficulty) and it has been proposed to use SDO markup to better train those NER systems. To make the story short, don't blur the lines between the Organization and Place types, but accommodate the fact an ORG can have offices located in places.

rtroncy commented Sep 11, 2017

I fully agree with the concerns made by @RichardWallis if SDO was mixing location and organizations. A different perspective comes from the Natural Language Processing research field where we teach machines to extract and disambiguate named entities of various types. One common mistake of all systems, is the proper distinction between the ORG and the LOC types, precisely because the way we use those entities in common language is confusing. Nevertheless, this distinction is important (challenges are even made to properly tackle this difficulty) and it has been proposed to use SDO markup to better train those NER systems. To make the story short, don't blur the lines between the Organization and Place types, but accommodate the fact an ORG can have offices located in places.

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Sep 11, 2017

Contributor
Contributor

rvguha commented Sep 11, 2017

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri
Contributor

danbri commented Sep 11, 2017

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Sep 11, 2017

Contributor
Contributor

mfhepp commented Sep 11, 2017

@RichardWallis

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Sep 12, 2017

Contributor

@mfhepp thanks for pointing that out, I'd missed it also.

So in essence we have the mechanism to associate an Organisation to the Place(s) (via the location property) that it operates from that cannot be considered to be a LocalBusiness

Contributor

RichardWallis commented Sep 12, 2017

@mfhepp thanks for pointing that out, I'd missed it also.

So in essence we have the mechanism to associate an Organisation to the Place(s) (via the location property) that it operates from that cannot be considered to be a LocalBusiness

@RichardWallis

This comment has been minimized.

Show comment
Hide comment
@RichardWallis

RichardWallis Sep 12, 2017

Contributor

oops, pressed the close button by mistake!

Continuing my comment....

As to identifying the type of location, we have the option of using the name of the place ("Global Corp Head Office", "Global Corp South American Distribution Center").

If there is concern that that is not detailed enough I would suggest a new subtype of Place (BusiniessPlace) with its own set of subtypes (Office, HeadOffice, Warehouse, ManufacturingLocation, DistributionCenter, ResearchCenter, etc.)

Contributor

RichardWallis commented Sep 12, 2017

oops, pressed the close button by mistake!

Continuing my comment....

As to identifying the type of location, we have the option of using the name of the place ("Global Corp Head Office", "Global Corp South American Distribution Center").

If there is concern that that is not detailed enough I would suggest a new subtype of Place (BusiniessPlace) with its own set of subtypes (Office, HeadOffice, Warehouse, ManufacturingLocation, DistributionCenter, ResearchCenter, etc.)

@rvguha

This comment has been minimized.

Show comment
Hide comment
@rvguha

rvguha Sep 12, 2017

Contributor
Contributor

rvguha commented Sep 12, 2017

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Sep 12, 2017

Contributor
Contributor

mfhepp commented Sep 12, 2017

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Sep 12, 2017

Contributor

To @rvguha's point, every ontology I have worked with has either been very verbose or conflated organizations and places. (The details of the conflation differ.) Schema.org has always had the philosophy that if there is a conflict, we make things easier for authors not readers.

Large sites like OpenTable already use things like Restaurant for chains, so if you are reading schema.org data, you either don't care about splitting the entities, or you have had to sort through splitting Ruth's Chris the Organization from Ruth's Chris, the location where I have my reservation.

Contributor

vholland commented Sep 12, 2017

To @rvguha's point, every ontology I have worked with has either been very verbose or conflated organizations and places. (The details of the conflation differ.) Schema.org has always had the philosophy that if there is a conflict, we make things easier for authors not readers.

Large sites like OpenTable already use things like Restaurant for chains, so if you are reading schema.org data, you either don't care about splitting the entities, or you have had to sort through splitting Ruth's Chris the Organization from Ruth's Chris, the location where I have my reservation.

@thadguidry

This comment has been minimized.

Show comment
Hide comment
@thadguidry

thadguidry Sep 12, 2017

@rvguha pointed out the stem of the problem. making it easier for publishers AND having a clear distinction between a place and an organization. I already use location for my needs and use the name of the Place, its fairly easy. Dunno what the big deal is in this thread actually. All the parts I need are already there and easy enough.

@jvandriel has a need which is "how do I tell a reader that an Organization has a head office?" That's the real problem. There is no direct property that currently tells you that in one leap. Fix that, and you have fixed this issue. (In Freebase, we did have such a property on our Organization type)

Do folks consider "address" on Organization has the primary head office, or do they like to use "location" ? Which one is more suited to this issue's use case of "marking a head office for an Organization on a map" ? I would think that "location" property (the one I use) to refer to a Place which can use "hasMap". I would think that a new property on Organization that replicates what we had in Freebase with "headOfficeLocation" or whatever and that is a type of Place would finalize this issue.

@RichardWallis If you want to have a ton of subtypes for every business place type..... s u r e. But that doesn't necessarily make @jvandriel life easier. I'd say it might make it much harder.

thadguidry commented Sep 12, 2017

@rvguha pointed out the stem of the problem. making it easier for publishers AND having a clear distinction between a place and an organization. I already use location for my needs and use the name of the Place, its fairly easy. Dunno what the big deal is in this thread actually. All the parts I need are already there and easy enough.

@jvandriel has a need which is "how do I tell a reader that an Organization has a head office?" That's the real problem. There is no direct property that currently tells you that in one leap. Fix that, and you have fixed this issue. (In Freebase, we did have such a property on our Organization type)

Do folks consider "address" on Organization has the primary head office, or do they like to use "location" ? Which one is more suited to this issue's use case of "marking a head office for an Organization on a map" ? I would think that "location" property (the one I use) to refer to a Place which can use "hasMap". I would think that a new property on Organization that replicates what we had in Freebase with "headOfficeLocation" or whatever and that is a type of Place would finalize this issue.

@RichardWallis If you want to have a ton of subtypes for every business place type..... s u r e. But that doesn't necessarily make @jvandriel life easier. I'd say it might make it much harder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment