hasMap can be applied to LocalBusiness, but not to Organization

[e-orlov]

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]

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.

[RichardWallis]

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]

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]

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]

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]

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]

I tend to contradict - why not use the clean route and link from the organization to a place? we may need a superproperty like hasOffice for hasPOS, but that make sense anyway.

…

--------------------------------------- martin hepp www: http://www.heppnetz.de/ email: mhepp@computer.org

On 7. Sep 2017, at 06:10, DDeering ***@***.***> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[mfhepp]

I tend to contradict - why not use the clean route and link from the organization to a place? we may need a superproperty like hasOffice for hasPOS, but that make sense anyway.

…

--------------------------------------- martin hepp www: http://www.heppnetz.de/ email: mhepp@computer.org

On 7. Sep 2017, at 06:10, DDeering ***@***.***> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[RichardWallis]

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.

[RichardWallis]

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]

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]

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]

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

[vholland]

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

[DDeering]

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]

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]

I think it will be very confusing to call every business that has any local presence a LocalBusiness. Amazon.com has offices in Seattle (and other places). It would be very very confusing if it was considered a 'LocalBusiness'. Martin, Richard, exactly what is the problem we are trying to solve here? guha

…

On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> .

[rvguha]

I think it will be very confusing to call every business that has any local presence a LocalBusiness. Amazon.com has offices in Seattle (and other places). It would be very very confusing if it was considered a 'LocalBusiness'. Martin, Richard, exactly what is the problem we are trying to solve here? guha

…

On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: 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. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> .

[RichardWallis]

@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.

[RichardWallis]

@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]

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]

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]

Ok, got it and agree that we should make the distinction, but consumers of the data should be prepared to cope with markup that has it confused. The problem with forcing the distinction is that for the little family tea shop round the corner, you are forced to have to entities. One for the business and one for the business location. While this is 'ontologically' more pure, it does complicate things for publishers. But we do want to be able to make the distinction. How about we introduce terms for DistributionCenter, OfficeLocation, RetailOutlet, etc. so that when we talk about Google's London office or the starbucks in grand central, the publisher can say what kind of thing it is. And yes, they can all be subclasses of BusinessLocation, but we should make sure we don't need two entities for the local small business. guha

…

On Mon, Sep 11, 2017 at 4:21 AM, Richard Wallis ***@***.***> wrote: @rvguha <https://github.com/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 <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCh2YxL7LIaKs5iC5cneYM-nMBdAfks5shRfCgaJpZM4POnXC> .

[rvguha]

Ok, got it and agree that we should make the distinction, but consumers of the data should be prepared to cope with markup that has it confused. The problem with forcing the distinction is that for the little family tea shop round the corner, you are forced to have to entities. One for the business and one for the business location. While this is 'ontologically' more pure, it does complicate things for publishers. But we do want to be able to make the distinction. How about we introduce terms for DistributionCenter, OfficeLocation, RetailOutlet, etc. so that when we talk about Google's London office or the starbucks in grand central, the publisher can say what kind of thing it is. And yes, they can all be subclasses of BusinessLocation, but we should make sure we don't need two entities for the local small business. guha

…

On Mon, Sep 11, 2017 at 4:21 AM, Richard Wallis ***@***.***> wrote: @rvguha <https://github.com/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 <https://github.com/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. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCh2YxL7LIaKs5iC5cneYM-nMBdAfks5shRfCgaJpZM4POnXC> .

[danbri]

http://schema.org/branchOf
http://schema.org/department make related distinctions

[danbri]

http://schema.org/branchOf
http://schema.org/department make related distinctions

[mfhepp]

Actually, I missed that we have http://schema.org/location This allows linking any Organization to one or more Place entities, that themselves can have all the properties for geo-related information, including hasMap. So I see no need for an extension. Simply model the offices as Places and you are fine. One could argue that a subtype "Office" of schema:Place could be needed, but I would counter that unless you need this distinction for any major consumer of data, using the plain "Place" type should be fine. We might find that some properties should move up from LocalBusiness to Place, but I did not check for candidates. But I strictly oppose copying properties that model aspects of a physical location to Organization as a legal entitity. There are organizations that have no physical location (e.g. the Schema.org Steering Group), and there are places that are not legal agents. Martin

…

----------------------------------- martin hepp http://www.heppnetz.de mhepp@computer.org @mfhepp

On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: I think it will be very confusing to call every business that has any local presence a LocalBusiness. Amazon.com has offices in Seattle (and other places). It would be very very confusing if it was considered a 'LocalBusiness'. Martin, Richard, exactly what is the problem we are trying to solve here? guha On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: > 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. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1734 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mfhepp]

Actually, I missed that we have http://schema.org/location This allows linking any Organization to one or more Place entities, that themselves can have all the properties for geo-related information, including hasMap. So I see no need for an extension. Simply model the offices as Places and you are fine. One could argue that a subtype "Office" of schema:Place could be needed, but I would counter that unless you need this distinction for any major consumer of data, using the plain "Place" type should be fine. We might find that some properties should move up from LocalBusiness to Place, but I did not check for candidates. But I strictly oppose copying properties that model aspects of a physical location to Organization as a legal entitity. There are organizations that have no physical location (e.g. the Schema.org Steering Group), and there are places that are not legal agents. Martin

…

----------------------------------- martin hepp http://www.heppnetz.de mhepp@computer.org @mfhepp

On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: I think it will be very confusing to call every business that has any local presence a LocalBusiness. Amazon.com has offices in Seattle (and other places). It would be very very confusing if it was considered a 'LocalBusiness'. Martin, Richard, exactly what is the problem we are trying to solve here? guha On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: > 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. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <#1734 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > . > — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[RichardWallis]

@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]

@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]

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.)

[RichardWallis]

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]

Martin, I think we should be open to copying some of the Place properties to organization. Metonymy happens. One option is to have the concept of a 'primary' domain/range, with other domain ranges being seen as metonymical uses. guha On Mon, Sep 11, 2017 at 12:32 PM, Martin Hepp <notifications@github.com> wrote:

…

Actually, I missed that we have http://schema.org/location This allows linking any Organization to one or more Place entities, that themselves can have all the properties for geo-related information, including hasMap. So I see no need for an extension. Simply model the offices as Places and you are fine. One could argue that a subtype "Office" of schema:Place could be needed, but I would counter that unless you need this distinction for any major consumer of data, using the plain "Place" type should be fine. We might find that some properties should move up from LocalBusiness to Place, but I did not check for candidates. But I strictly oppose copying properties that model aspects of a physical location to Organization as a legal entitity. There are organizations that have no physical location (e.g. the Schema.org Steering Group), and there are places that are not legal agents. Martin ----------------------------------- martin hepp http://www.heppnetz.de ***@***.*** @mfhepp > On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: > > I think it will be very confusing to call every business that has any local > presence a LocalBusiness. > > Amazon.com has offices in Seattle (and other places). It would be very very > confusing if it was considered a 'LocalBusiness'. > > Martin, Richard, exactly what is the problem we are trying to solve here? > > guha > > On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: > > > 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. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#1734# issuecomment-327854492>, > > or mute the thread > > <https://github.com/notifications/unsubscribe-auth/ AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > > . > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCh7e9J2Ex8DNgD7zGpaRbGPNa0E0ks5shYrRgaJpZM4POnXC> .

[rvguha]

Martin, I think we should be open to copying some of the Place properties to organization. Metonymy happens. One option is to have the concept of a 'primary' domain/range, with other domain ranges being seen as metonymical uses. guha On Mon, Sep 11, 2017 at 12:32 PM, Martin Hepp <notifications@github.com> wrote:

…

Actually, I missed that we have http://schema.org/location This allows linking any Organization to one or more Place entities, that themselves can have all the properties for geo-related information, including hasMap. So I see no need for an extension. Simply model the offices as Places and you are fine. One could argue that a subtype "Office" of schema:Place could be needed, but I would counter that unless you need this distinction for any major consumer of data, using the plain "Place" type should be fine. We might find that some properties should move up from LocalBusiness to Place, but I did not check for candidates. But I strictly oppose copying properties that model aspects of a physical location to Organization as a legal entitity. There are organizations that have no physical location (e.g. the Schema.org Steering Group), and there are places that are not legal agents. Martin ----------------------------------- martin hepp http://www.heppnetz.de ***@***.*** @mfhepp > On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: > > I think it will be very confusing to call every business that has any local > presence a LocalBusiness. > > Amazon.com has offices in Seattle (and other places). It would be very very > confusing if it was considered a 'LocalBusiness'. > > Martin, Richard, exactly what is the problem we are trying to solve here? > > guha > > On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> wrote: > > > 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. > > > > — > > You are receiving this because you are subscribed to this thread. > > Reply to this email directly, view it on GitHub > > <#1734# issuecomment-327854492>, > > or mute the thread > > <https://github.com/notifications/unsubscribe-auth/ AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > > . > > > — > You are receiving this because you commented. > Reply to this email directly, view it on GitHub, or mute the thread. > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1734 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFAlCh7e9J2Ex8DNgD7zGpaRbGPNa0E0ks5shYrRgaJpZM4POnXC> .

[mfhepp]

Dear Guha: I tend to disagree - it is straightforward to define an Organization and then link to its Place or Places via schema:location and attach all required properties thereto. Or if you really want to go the route of having just one entity, then make it a multi-typed being both an Organization and a Place. Martin ----------------------------------- martin hepp http://www.heppnetz.de mhepp@computer.org @mfhepp

…

On 12 Sep 2017, at 20:21, R.V.Guha ***@***.***> wrote: Martin, I think we should be open to copying some of the Place properties to organization. Metonymy happens. One option is to have the concept of a 'primary' domain/range, with other domain ranges being seen as metonymical uses. guha On Mon, Sep 11, 2017 at 12:32 PM, Martin Hepp ***@***.***> wrote: > Actually, I missed that we have > > http://schema.org/location > > This allows linking any Organization to one or more Place entities, that > themselves can have all the properties for geo-related information, > including hasMap. > > So I see no need for an extension. > > Simply model the offices as Places and you are fine. > > One could argue that a subtype "Office" of schema:Place could be needed, > but I would counter that unless you need this distinction for any major > consumer of data, using the plain "Place" type should be fine. > > We might find that some properties should move up from LocalBusiness to > Place, but I did not check for candidates. > > But I strictly oppose copying properties that model aspects of a physical > location to Organization as a legal entitity. There are organizations that > have no physical location (e.g. the Schema.org Steering Group), and there > are places that are not legal agents. > > Martin > > > ----------------------------------- > martin hepp http://www.heppnetz.de > ***@***.*** @mfhepp > > > > > > On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: > > > > I think it will be very confusing to call every business that has any > local > > presence a LocalBusiness. > > > > Amazon.com has offices in Seattle (and other places). It would be very > very > > confusing if it was considered a 'LocalBusiness'. > > > > Martin, Richard, exactly what is the problem we are trying to solve here? > > > > guha > > > > On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> > wrote: > > > > > 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. > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#1734# > issuecomment-327854492>, > > > or mute the thread > > > <https://github.com/notifications/unsubscribe-auth/ > AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > > > . > > > > > — > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub, or mute the thread. > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1734 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAlCh7e9J2Ex8DNgD7zGpaRbGPNa0E0ks5shYrRgaJpZM4POnXC> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[mfhepp]

Dear Guha: I tend to disagree - it is straightforward to define an Organization and then link to its Place or Places via schema:location and attach all required properties thereto. Or if you really want to go the route of having just one entity, then make it a multi-typed being both an Organization and a Place. Martin ----------------------------------- martin hepp http://www.heppnetz.de mhepp@computer.org @mfhepp

…

On 12 Sep 2017, at 20:21, R.V.Guha ***@***.***> wrote: Martin, I think we should be open to copying some of the Place properties to organization. Metonymy happens. One option is to have the concept of a 'primary' domain/range, with other domain ranges being seen as metonymical uses. guha On Mon, Sep 11, 2017 at 12:32 PM, Martin Hepp ***@***.***> wrote: > Actually, I missed that we have > > http://schema.org/location > > This allows linking any Organization to one or more Place entities, that > themselves can have all the properties for geo-related information, > including hasMap. > > So I see no need for an extension. > > Simply model the offices as Places and you are fine. > > One could argue that a subtype "Office" of schema:Place could be needed, > but I would counter that unless you need this distinction for any major > consumer of data, using the plain "Place" type should be fine. > > We might find that some properties should move up from LocalBusiness to > Place, but I did not check for candidates. > > But I strictly oppose copying properties that model aspects of a physical > location to Organization as a legal entitity. There are organizations that > have no physical location (e.g. the Schema.org Steering Group), and there > are places that are not legal agents. > > Martin > > > ----------------------------------- > martin hepp http://www.heppnetz.de > ***@***.*** @mfhepp > > > > > > On 09 Sep 2017, at 22:21, R.V.Guha ***@***.***> wrote: > > > > I think it will be very confusing to call every business that has any > local > > presence a LocalBusiness. > > > > Amazon.com has offices in Seattle (and other places). It would be very > very > > confusing if it was considered a 'LocalBusiness'. > > > > Martin, Richard, exactly what is the problem we are trying to solve here? > > > > guha > > > > On Thu, Sep 7, 2017 at 9:35 AM, DDeering ***@***.***> > wrote: > > > > > 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. > > > > > > — > > > You are receiving this because you are subscribed to this thread. > > > Reply to this email directly, view it on GitHub > > > <#1734# > issuecomment-327854492>, > > > or mute the thread > > > <https://github.com/notifications/unsubscribe-auth/ > AFAlClfCjiMBYUpXKGkOB2pl4x4-1b5uks5sgBtJgaJpZM4POnXC> > > > . > > > > > — > > You are receiving this because you commented. > > > Reply to this email directly, view it on GitHub, or mute the thread. > > > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#1734 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AFAlCh7e9J2Ex8DNgD7zGpaRbGPNa0E0ks5shYrRgaJpZM4POnXC> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[vholland]

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.

[vholland]

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]

@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]

@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.