Create subtype of ItemList for OfferCatalog

[vholland]

When http://schema.org/ItemList was revamped, one of the use cases was a catalog. The second example is for one such use case.

As this is a common use case and seeing adoption, it would be nice to add a separate type for it:

_OfferCatalog_: An OfferCatalog is an ItemList that contains Offers and/or further OfferCatalogs. _hasOfferCatalog_: Indicates an OfferCatalog listing for this Service or Organization.

[vholland]

Created pull request #821.

[jvandriel]

Just to make sure I get this right @vholland, do you mean this type would be the preferred type for a product listing page?

[vholland]

@jvandriel to be pendantic, it would be the preferred type for offers. For example, Amazon's catalog could be a giant OfferCatalog.

Something strange like all the Products I own would be an odd use of this type.

[jvandriel]

"All the products I own" would indeed be a bit strange. :)

I was more thinking along the lines of product listing pages on ecommerce sites, which generally are modelled from a schema.org/Product POV and not from an schema.org/Offer POV.

[danbri]

I'll merge this into sdo-phobos to aid with reviewing it - easier to understand in context vs reading config file markup I think.

[danbri]

FYI: http://sdo-phobos.appspot.com/OfferCatalog - queued for final review

[jvandriel]

I'm still struggling to understand what type of page you imagine using schema.org/OfferCatalog for @vholland. Do you mean something like this: http://www.amazon.com/Catalogs-Directories-Reference-Books/b ?

And why the sudden change from modeling such data from a schema.org/Product POV to an schema.org/Offer POV?

After all, it's goes against what's been promoted over the years and thus isn't something most webmasters are accustomed to. From that POV having a ServiceCatalog and ProductCatalog would make more sense to me.

Especially since most working on ecommerce sites think of catalog pages as product listing pages.

[danbri]

I've opened an issue https://github.com/schemaorg/schemaorg/issues/827 for tracking final review comments, and have stopped making active changes to the schemas/examples/docs. Keep discussing here please but we'll use #827 to track final review comments and make a hopefully final round of edits when things settle down (I'd guess we need about a week, but let's see :)

[vholland]

There are multiple threads across various pull requests and issues. Trying to tie together:

• Re: Pull request #828: I am fine with using makesOffer to link an Organization to an OfferCatalog.
• Re: Pull request #821: I am fine with @mfhepp's suggestion of changing hasOfferCatalog to serviceDetails.

Implementation should be discussed in issue #827 so people know what they are signing off on.

[danbri]

Thanks @vholland - sounds good to me. Any objections to proceeding in that direction from others here? If not let's make the changes towards the end of the week, to give time for other reviewers.

[mfhepp]

+1 to the current proposal with using makesOffer to link an Organization to an OfferCatalog and changing hasOfferCatalog to serviceDetails.

[danbri]

@pmika @chaals @tilid @ajax-als @scor @shankarnat any preferences? can we close this last design question as outlined by @vholland above?

[shankarnat]

+1 to the proposal by @vholland

[danbri]

Hearing no objections after a week of @vholland 's proposal, and noting @shankarnat 's +1, I think we have a decision. @vholland I do these manually unless you have a pull request handy...

[vholland]

@danbri I sent pull request #843 with the fixes described above.

[mfhepp]

843 looks good to me.

+1

[rvguha]

Sorry, I am not ok with renaming hasOfferCatalog to serviceDetails.

hasOfferCatalog has a simple clear unambiguous meaning and people will use it. serviceDetails sounds like something from the boiler plate of the terms of service of some ... Not at all clear what it means and it will either not get used or misused.

guha

On Tue, Oct 13, 2015 at 10:44 AM, Martin Hepp notifications@github.com wrote:

843 https://github.com/schemaorg/schemaorg/pull/843 looks good to me.

+1

— Reply to this email directly or view it on GitHub https://github.com/schemaorg/schemaorg/issues/818#issuecomment-147790404 .

[mfhepp]

I can live with hasOfferCatalog, as long as this is only applied to Service, not to Person or Organization. For those two, we should use makesOffer as in the latest pull-request.

Martin

---

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

On 13 Oct 2015, at 18:55, R.V.Guha notifications@github.com wrote:

Sorry, I am not ok with renaming hasOfferCatalog to serviceDetails.

hasOfferCatalog has a simple clear unambiguous meaning and people will use it. serviceDetails sounds like something from the boiler plate of the terms of service of some ... Not at all clear what it means and it will either not get used or misused.

guha

On Tue, Oct 13, 2015 at 10:44 AM, Martin Hepp notifications@github.com wrote:

843 https://github.com/schemaorg/schemaorg/pull/843 looks good to me.

+1

— Reply to this email directly or view it on GitHub https://github.com/schemaorg/schemaorg/issues/818#issuecomment-147790404 .

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

[rvguha]

A business organization should be able to have a service catalog

guha

On Wed, Oct 14, 2015 at 4:26 AM, Martin Hepp notifications@github.com wrote:

I can live with hasOfferCatalog, as long as this is only applied to Service, not to Person or Organization. For those two, we should use makesOffer as in the latest pull-request.

Martin

---

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

On 13 Oct 2015, at 18:55, R.V.Guha notifications@github.com wrote:

Sorry, I am not ok with renaming hasOfferCatalog to serviceDetails.

hasOfferCatalog has a simple clear unambiguous meaning and people will use it. serviceDetails sounds like something from the boiler plate of the terms of service of some ... Not at all clear what it means and it will either not get used or misused.

guha

On Tue, Oct 13, 2015 at 10:44 AM, Martin Hepp notifications@github.com wrote:

843 https://github.com/schemaorg/schemaorg/pull/843 looks good to

me. +1

— Reply to this email directly or view it on GitHub < https://github.com/schemaorg/schemaorg/issues/818#issuecomment-147790404> .

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

— Reply to this email directly or view it on GitHub https://github.com/schemaorg/schemaorg/issues/818#issuecomment-148022686 .

[elf-pavlik]

A business organization should be able to have a service catalog

:+1: Organization (agent) offers services, not a Service offers services https://github.com/schemaorg/schemaorg/pull/821#issuecomment-146251942

If we just use:

Organization - makesOffer -> OfferCatalog | Offer

than "organizaiton has a service catalog", together with

Service - provider -> Organization

provides way to always 'follow our nose' and start again

Organization - makesOffer -> OfferCatalog | Offer

[danbri]

Ping @vholland - can you summarize any rough consensus here as you see it? do we stick with hasOfferCatalog? @mfhepp can you live with hasOfferCatalog being allowed on Person and Organization too?

[vholland]

As I understand it, there is consensus for reverting to using hasOfferCatalog instead of serviceDetails.

The issue at hand is whether hasOfferCatalog is allowed on Person and Organization or whether those types use makesOffer. The object of makesOffer may be an OfferCatalog in that instance.

For symmetry, I prefer allowing hasOfferCatalog on Person and Organization, but others should chime in before I change the pull request.

[mfhepp]

Sorry to be harsh, but if we open just another side-track from Person/Organization to Offer, we start to say farewell to the currently pretty clean conceptual core of the Agent-Promise-Object-Compensation pattern. Why can't we simply broaden makesOffer to cover the need for an OfferCatalog as proposed?

[rvguha]

I think we need to be flexible about patterns.

I propose we go with Vicki's suggestion.

guha

On Wed, Oct 21, 2015 at 9:40 AM, Martin Hepp notifications@github.com wrote:

Sorry to be harsh, but if we open just another side-track from Person/Organization to Offer, we start to say farewell to the currently pretty clean conceptual core of the Agent-Promise-Object-Compensation pattern. Why can't we simply broaden makesOffer to cover the need for an OfferCatalog as proposed?

— Reply to this email directly or view it on GitHub https://github.com/schemaorg/schemaorg/issues/818#issuecomment-149955467 .

[mfhepp]

@danbri let's put it that way: I won't die of a broken heart if hasOfferCatalog will be added. But it is in my opinion an unnecessary step away from some degree of conceptual clarity towards a very loosely organized "bag of words" vocabulary approach in schema.org, and it dilutes the underlying GoodRelations model. Most of my motivation to contribute to schema.org stems from the fact that I think preserving the core elements of GoodRelations against accidental and intended duplications and conflicts in domain-specific extension proposals is a very valuable goal that will pay out for schema.org over time. If this becomes I hopeless endeavor there is reason to be concerned, IMO. I am also not very happy with the form of the discussion and decision-making in this particular case.

[jvandriel]

At first glance I thought I'd prefer makesOffer but I guess that also implies we'd have to add offerredBy to schema.org/OfferCatalog. Which I think is too much given the fact each individual schema.org/Offer already has that property.

So +1 for hasOfferCatalog.

[danbri]

@mfhepp - interesting that it feels more "bag of words" to you. My reading is that this brings a lot more potentially useful structure, via ItemList, than simply repeating a property whose value is an Offer. So you keep the clarity of the Offer-based model but also get some insight into how a potentially large collection of offers are structured.

[elf-pavlik]

My reading is that this brings a lot more potentially useful structure, via ItemList, than simply repeating a property whose value is an Offer.

If people find this useful also for other types than Offer, do you also plan to add an additional property for each property with schema:rangeIncludes schema:ItemList? So far I only see it 'hinted' as value for schema:track and schema:recipeInstructions (plus schema:breadcrumb on schema:BreadcrumbList sub type)

Focusing on schema:Organization, for schema:Person this could result in schema:member and schema:hasMembersDirectory, for schema:Event - schema:event and schema:hasEventsCalendar, for schema:Place - schema:areaServed and schema:hasAreaServedMap etc.

Since schema.org already uses schema:rangeIncludes instead of rdfs:range and in many cases allow schema:Role, maybe similar pattern could work to also allow schema:ItemsList as value of any property.

AS2.0 has similar challenge of linking to as:Collection https://github.com/jasnell/w3c-socialwg-activitystreams/pull/191

[danbri]

@elf-pavlik I think at this point there is little indication that doing so would be useful. I know from investigating consumption of offer descriptions that such structure would help and encourage consumption; but I'm skeptical that exactly the same pattern will be useful everywhere.

[vholland]

As I read the thread, we have agreed that http://schema.org/Service will have the property hasOfferCatalog.

The remaining discussion is whether Person and Organization should also have haveOfferCatalog.

As @danbri suggested, a series of makesOffer properties does not give any sense of structure. By creating an OfferCatalog, we can demonstrate how Offers can inherit from one another through the use of sub-catalogs that group like offers.

Something like:

<script type="application/ld+json">
{
  "@context": "http://schema.org/",
  "@type": "Service",
  "serviceType": "Weekly home cleaning",
  "provider": {
    "@type": "LocalBusiness",
    "name": "ACME Home Cleaning"
  },
  "areaServed": {
    "@type": "State",
    "name": "Massachusetts"
  },
  "hasOfferCatalog": {
    "@type": "OfferCatalog",
    "name": "Cleaning services",
    "itemListElement": [
      {
        "@type": "OfferCatalog",
        "name": "House Cleaning",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Apartment light cleaning"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "House light cleaning up to 2 bedrooms"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "House light cleaning 3+ bedrooms"
            }
          }
        ]
      },
      {
        "@type": "OfferCatalog",
        "name": "One-time services",
        "itemListElement": [
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Window washing"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Carpet cleaning"
            }
          },
          {
            "@type": "Offer",
            "itemOffered": {
              "@type": "Service",
              "name": "Move in/out cleaning"
            }
          }
        ]
      }
    ]
  }
}
</script>

I suggest we:

1. Add hasOfferCatalog to Person and Organization.
2. Modify the description of hasOfferCatalog to reflect it is for expressing many, related Offers from the same Person, Organization, or Service.
3. Modify the description of makesOffer to reflect it is used for expressing Offers without implying an relationship between the individual offers.

[danbri]

Thanks @vholland . I guess I'd express it the other way around, rather than saying what makesOffer doesn't imply, we should say what the combination of hasOfferCatalog + OfferCatalog does.

I believe we're saying something like: "Any Offer 'X' that is directly or indirectly contained within an OfferCatalog (i.e. including recursively) that is a the value of hasOfferCatalog on some Service S, implies that S makesOffer 'X'. This could doubtless be phrased more gracefully and/or formally. My feeling is that OfferCatalog is the place to document this.

[jvandriel]

MIght it be an idea to create examples based on some actual web pages containing OfferCatalogs?

I can't escape feeling this whole discussion is becoming more and more a hypothetical exercise, and a Github issue labyrinth to keep up with, than that is based on resolving real-life situations.

Please let's make the discussion a bit more practical (I'm really having a hard time keeping up with what this is trying to resolve).

[danbri]

@jvandriel do you find @vholland 's example markup above too idealized?

[elf-pavlik]

1. Modify the description of hasOfferCatalog to reflect it is for expressing many, related Offers from the same Person, Organization, or Service.

Please let me know if I should not mention any more anything about my observation of potentially mixing agents Person, Organization with goods Service.

While agents: Person or Organization do offer certain Service (or Product) via Offer, and now also wiht inderection of OfferCatalog. Service only has various relevant offers of more specific services, and links to the agent who does offer it with schema:provider.

Agent - makesOffer -> Offer Agent - hasOfferCatalog -> OfferCatalog

Service - offers -> Offer Service - hasOfferCatalog -> OfferCatalog Service - provider -> Agent

Actually I will just not mention it any more, I believe I repeated it already 3 times so most likely no one else sees any issue here and I just worry to much about keeping agents clearly distinct from goods which they offer (or seek).

[vholland]

@elf-pavlik I understand your argument, but splitting entities between their agent and non-agent facets is difficult and well beyond the average webmaster. For example, look at most schemas. How do they deal with organizations and their locations? Often the same entity is typed as both (as we do in schema.org with http://schema.org/LocalBusiness), despite the organization being an agent and the location being a non-agent.

[mfhepp]

@vholland @danbri @rvguha To bring this to a fruitful end:

1. I can live with hsOfferCatalog on Service, weaking the basic GoodRelations model for services, because services are just a inherently difficult topic to model, and strengthening the GoodRelations patterns for typical products is a good side-effect of this.
2. As for hasOffer on Person and Organization: After some consideration and friendly input from Dan, I am now also fine with this. I can simply add an additional axiom to the list of non-standard axioms in the GoodRelations documentation at http://wiki.goodrelations-vocabulary.org/Axioms that says

IF ?a rdf:type schema:Person OR schema:Organization AND ?a schema:hasOfferCatalog ?b AND ?b schema:itemListElement ?c AND ?c rdf:type schema:Offer THEN INSERT

?a schema:makesOffer ?c

This can be easily done in SPARQL or any other rule language and will mean that the addition of hasOfferCatalog and OfferList will not break the existing Agent-Promise-Object pattern.

Martin

[elf-pavlik]

@vholland thank you for contrasting it to http://schema.org/LocalBusiness very likely it makes sense to expect that publishers might conflate Service and Organization. As I said I will just leave this topic alone, especially that you stay aware about this possible issue.

@mfhepp

IF ?a rdf:type schema:Person OR schema:Organization AND ?a schema:hasOfferCatalog ?b AND ?b schema:itemListElement ?c AND ?c rdf:type schema:Offer THEN INSERT

?a schema:makesOffer ?c

This doesn't seem to account for possible additional schema:ListItem indirection:

Agent - hasOfferCatalog -> OfferCatalog - itemListElement -> ListItem - item -> Offer

[vholland]

I made the changes in pull request #852

[jvandriel]

"do you find @vholland 's example markup above too idealized?"

No, it's just that this entire discussion is being held over so many different issues while being quite volatile that I got lost in it. Talking in abstracts stays my weak spot, yet when I see examples that illustrate 'it's this type of page' what this proposal is trying to encompass, than things make more sense to me. ;)

One thing that still feels a bit weird to me though is the idea of nesting OfferCatalog instances because it gives me the impression it's a method for categorizing lists without having categories. And I don't see how this should be translated to actual website makup, as these often provide lists based on categories.

[danbri]

Thanks everyone. "And that's a wrap" as they say on TV...

@vholland I've merged that last #852 from you, but I'm missing why hasOfferCatalog isn't also being attached to Organization.

[danbri]

OK I've updated the test build from http://sdo-phobos.appspot.com/hasOfferCatalog please take a look.

Wrap-up points (implemented already):

• The text until just now said "An OfferCatalog is an ItemList that contains related Offers and/or further OfferCatalogs from the same seller." --- shouldn't this be 'provider' or 'party' or something more neutral (per offeredBy and not-for-profit discussion).
• I wanted to say that being in the OfferCatalog implies that it is offered ... (helping anchor this construct in the underlying Offer-based pattern, as urged by @mfhepp ).

I believe both of these are addressed with the following tweak. New and hopefully final text is:

<span property="rdfs:comment">An OfferCatalog is an ItemList that contains related Offers 
and/or further OfferCatalogs that are offeredBy the same provider.</span>

[mfhepp]

+1

---

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

[vholland]

@danbri In all of the going back and forth on this, the previous state already had hasOfferCatalog on Organization. I had never removed it because I was not sure where the discussion would land and did not want to churn needlessly.

[danbri]

@vholland - thanks. I realised it was there when I published the build. I think we're fine now.

[danbri]

Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all