In general, I think the approach makes sense, but I would suggest to expand the range of makesOffer to include OfferCatalog (and of seeks, too). So makesOffer can either point to a single Offer or to an OfferCatalog.

Also, I think that naming OfferCatalog OfferList would be more consistent and make clear that it is a subtype of ItemList.

Lastly, note that we do only need OfferCatalog if we need to preserve the order of the items, i.e. nextItem, previousItem, or position properties from ListItem. Otherwise, I see no difference to simply attaching multiple offers to the Organization via makesOffer. In JSON-LD and Microdata, this would be an ordered list in its own right. In RDFa, it would be an unordered list.

But again - we only need this if specifying the order is critical, or if we want to attach a name to the list.

By the way, in both cases I think we could simply combine ItemList with Offer as it stands.

There may be properties that apply to all the offers in an OfferCatalog
that can be specified at a Catalog level.

The term Catalog makes sense, because it corresponds to the Catalogs that
are provided by shops.

guha

On Thu, Oct 1, 2015 at 11:59 AM, Martin Hepp [email protected]
wrote:

In general, I think the approach makes sense, but I would suggest to
expand the range of makesOffer to include OfferCatalog (and of seeks, too).
So makesOffer can either point to a single Offer or to an OfferCatalog.

Also, I think that naming OfferCatalog OfferList would be more consistent
and make clear that it is a subtype of ItemList.

Lastly, note that we do only need OfferCatalog if we need to preserve the
order of the items, i.e. nextItem, previousItem, or position properties
from ListItem. Otherwise, I see no difference to simply attaching multiple
offers to the Organization via makesOffer. In JSON-LD and Microdata, this
would be an ordered list in its own right. In RDFa, it would be an
unordered list.

But again - we only need this if specifying the order is critical, or if
we want to attach a name to the list.

By the way, in both cases I think we could simply combine ItemList with
Offer as it stands.

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

I term Catalog makes sense to me. It could take some of the pressure off the term Collection.

Jeff

From: R.V.Guha [mailto:[email protected]]
Sent: Friday, October 02, 2015 9:58 AM
To: schemaorg/schemaorg
Subject: Re: [schemaorg] Issue #818: Added OfferCatalog and hasOfferCatalog. (#821)

There may be properties that apply to all the offers in an OfferCatalog
that can be specified at a Catalog level.

The term Catalog makes sense, because it corresponds to the Catalogs that
are provided by shops.

guha

On Thu, Oct 1, 2015 at 11:59 AM, Martin Hepp <[email protected]mailto:[email protected]>
wrote:

In general, I think the approach makes sense, but I would suggest to
expand the range of makesOffer to include OfferCatalog (and of seeks, too).
So makesOffer can either point to a single Offer or to an OfferCatalog.

Also, I think that naming OfferCatalog OfferList would be more consistent
and make clear that it is a subtype of ItemList.

Lastly, note that we do only need OfferCatalog if we need to preserve the
order of the items, i.e. nextItem, previousItem, or position properties
from ListItem. Otherwise, I see no difference to simply attaching multiple
offers to the Organization via makesOffer. In JSON-LD and Microdata, this
would be an ordered list in its own right. In RDFa, it would be an
unordered list.

But again - we only need this if specifying the order is critical, or if
we want to attach a name to the list.

By the way, in both cases I think we could simply combine ItemList with
Offer as it stands.

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

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/821#issuecomment-145029043.

I don't want to be nitpicky but do you have an example of a possible use case?

First off I have doubts we need this type as there are plenty of methods for chaining recurring data to offers, products and services.

Secondly I think @mfhepp has a valid point with: "we only need this if specifying the order is critical, or if we want to attach a name to the list"

Most off all because "I see no difference to simply attaching multiple offers to the Organization via makesOffer."

And lastly, I tend to disagree with @rvguha's statement: "The term Catalog makes sense, because it corresponds to the Catalogs that are provided by shops."

In all my years of working on ecommerce sites I've never heard any website stakeholder speak about a catalog nor about a catalog of offers. Stakeholders simply speak about product listings and/or service listings.

A catalog reminds me of those things that were popular during the print era. In digital environments most simply speak about 'listings', which - at least for me - makes using schema.org/XXXList a label that makes much more sense.

An important part is the Catalog may have sections (or sub-catalogs) with Offers as the leaf nodes. Perhaps I should improve the example to be something more like:

"@type": "OfferCatalog",
  "itemListElement": [
      {
        "@type": "OfferCatalog",
        "name": "Home 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": "OfferCatalog",
        "name": "Miscellaneous",
        "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"
         }
      }
    ]
  }
}

Showing the hierarchical aspect does help, yes.

Thanks for the example, that helps indeed. :)

Any chance you also have some webpage examples you think this might be interesting for?

(NOT to be stubborn but simply because I'm curious as in my 6/7 years of working with structured data I've never come across a site/page where I thought: "mmm, I wish there was a catalog type" (not even one that comes close to your newest example).

@jvandriel there are probably various pages this kind of data could be stuffed inside, but looking to the future it isn't so far fetched to imagine that the HTML wrapper isn't always entirely necessary. Whether or not this happens I would encourage you not to worry so much about which page it would have to live on, but rather think about whether the vocabulary lines up reasonably well with the kind of information available within a site.

Thanks for explaining that @danbri, and I agree with "looking to the future..."

Last question, keeping the here and now in mind as well, do you think it would be best practice if ecommerce sites start using schema.org/OfferCatalog for product listing pages or do you consider CollectionPage > mainEntity > ItemList to be valid markup for this as well?

(and no, not from a Google POV but conceptually. I know I'm the SEO here but I'm not fishing for any handouts. I'm just curious what your view on this is, and what the others participating here think)

My belief is that OfferCatalog adds clear value, and that its relationship with other possible idioms will shake out over time.

In general, I think the approach makes sense, but I would suggest to expand the range of makesOffer to include OfferCatalog (and of seeks, too). So makesOffer can either point to a single Offer or to an OfferCatalog.

@mfhepp what do you think about adding hasOfferCatalog? it also looks like now one needs to check two properties makesOffer and hasOfferCatalog to find possible offers. It looks like OfferCatalog can nest as items more OfferCatalog which may require recursive search for offers...

An important part is the Catalog may have sections (or sub-catalogs) with Offers as the leaf nodes.

Did someone consider using pattern specified in LDP Direct Container and similar one discussed in Hydra Collection Design?

Since none of properties uses rdfs:range and many accept schema:Role, why not even simply allow in similar way schema:ItemList for value of all the properties?

I can live with the name OfferCatalog and the general pattern, but I strongly suggest to rather expand the range of makesOffer to include OfferCatalog rather than introducing hasOfferCatalog, or , ate least, recommend hasOfferCatalog for Service only and use makesOffer for Organizations -> makesOffer -> OfferCatalog.

Otherwise, linking from the Organization or Person who makes all those offers is cumbersome - you would have to include many offeredBy statements with a link to the offering entity.

makesOffer would be more intuitive:

So here is my proposal:

1. Expand the range of makesOffer to include OfferCatalog
2. Remove Organization from the domain of hasOfferCatalog and update the text to reflect that this is just for services and that for organizations, makesOffer is the property to use.
3. Update the examples.

Minor change, but I think worth the effort

By the way, I now see value in the OfferCatalog type, because it may pave the way for a new JSON-LD-based product feed format.

Very minor: We should have a clear understanding of the difference between OfferCatalog and AggregateOffer. My assumption is that AggregateOffer is for multiple offers of the same product (or very similar ones) by different vendors , while OfferCatalog is for different items offered by the sane vendor.

Last point: Do we also need ProductCatalog for lists of products (ProductModels) without offers?

ate least, recommend hasOfferCatalog for Service only
...
Last point: Do we also need ProductCatalog for lists of products (ProductModels) without offers?

Why OfferCatalog than and not ServiceCatalog?

This would also address #801 (comment)

• LocalBusiness - hasServiceCatalog -> ServiceCatalog (no Offer in between but each Service can links to its offers)
• LocalBusiness - makesOffer -> Offer - itemOffered -> Service

@danbri @vholland I just submitted a PR for my changes as proposed above:

#828

I think that would do the trick.

As for @elf-pavlik: The OfferCatalog holds offers of services, not services. So OfferCatalog is fine.

We might need a ProductCatalog for ProductModels without offers (e.g. on manufacturers' pages), but not ServiceCatalog, since we do not use the ProductModel notion for services (it does not fit there very well - in practice).

Thanks @mfhepp, as I mentioned in #818 let's hold off on further active changes to give people time to review a stable target. But it helps to have this tweak as a pull request - cheers :)

@mfhepp re: AggregateOffer, yes, exactly. AggregateOffer is for multiple offers of the same product. It was the inability to express multiple products/services being offered.

Ooops I missed a piece.

I am fine with expanding makesOffer instead of adding hasOfferCatalog.

I will be traveling soon, but can create a pull request Monday if necessary.

+1 for recycling makesOffer - I'll note this in #827

Thanks but note that we should not use makesOffer for linking from Service to OfferCatalog. If you want to maintain that pattern, we need hasOfferCatalog.

But you have to decide whether that route is needed or whether makesOffer or offeredBy with a link to the Organization or Person are sufficient.

@vholland The pull request is already there. If agreed, we could add an example for the Organization -> makesOffer -> OfferCatalog route, but I would want to wait with that until the model is finalized.

Ah ok, misread you. Sounds like we're converging - let's pick this up after the weekend!

Yes, on a more abstract level, I accept that services may require different modeling patterns in schema.org in some cases - as long as we agree that as soon as we are talking of commercial aspects like prices, Offer remains the core type.

any reason we prefer hasOfferCatalog rather than offerCatalog?

Try saying "offerCatalog" and "OfferCatalog" on the phone to someone - it can be very confusing since we have a type of that name - sdo-phobos.appspot.com/OfferCatalog

Schema.org has a few cases of a type + property with same name (except for case) but we are trying not to add more...

I still find it confusing in ACME Home Cleaning offers a variety of services in Massachusetts example to have:
Service - hasOfferCatalog -> OfferCatalog - itemListElement -> Offer -> itemOffered -> Service

In case where OfferCatalog would appear as root element how does one specify the provider? hasOfferCatalog doesn't have a reverse property.

Why not to just start from Organization

Organization - makesOffer -> OfferCatalog - itemListElement -> Offer -> itemOffered -> Service

Or make OfferCatalog or root element and go from here to Organization following offeredBy property

Can even in ACME Home Cleaning example, the top level Service "serviceType": "Home cleaning" appear as value of itemOffered in the Offer? If not, I have impression that Service type here gets used in two different ways and some confusion around it still exists.

@elf-pavlik we may argue about the name hasOfferCatalog, but I think it makes sense to have a property that links from a generic Service description to the individual services. We could name it hasServicesCatalog or servicesDetails:

Service -> servicesDetails ->OfferCatalog - itemListElement -> Offer -> itemOffered -> Service

I assume the hasOfferCatalog name was inspired by the original usage for product and services offers.

If makesOffer and offeredBy will accept OfferCatalog, why not also extend rangeIncludes of schema:offers - which already happen to have plural name ❓ Otherwise one will need to use offers to link to individual offers from Service and hasOfferCatalog to link to the collection - catalog.

Once again I can imagine often a case where OfferCatalog might appear as root on the page, if hasOfferCatalog goes through #828 helps a lot by hinting use of offeredBy.

@elf-pavlik : If OfferCatalog would be accepted by makesOffer, this could allow mark-up for products with variants, on the same Product page. Is this one benefit you were thinking ? Because it would be wonderful, IMHO.

@radusi I just don't like idea of creating a new properties with the same meaning but which accept ItemList instead of simply multiple Things. I already mentioned at least two different patterns which help avoid it. Can you maybe write an example where you need OfferCatalog to include multiple product variants on the same page, and can't do it by simply using multiple Offers?

@elf-pavlik listing multiple Offers loses any sense of hierarchy or categorization of the Offers. For example, it is useful to know a cleaning service offers home vs commercial cleaning without knowing the specific prices of building size or whether carpet cleaning is included.

We could achieve the same result with serviceType, but authors are often bad at making that a reliable signal. If their services database already includes some hierarchy, it is easier to let them express that as a seperate sub-catalog.

Does the whole OfferCatalog have to appear on a single web page or it also provides a way to split it across multiple web pages (in such case an example would help)?

@elf-pavlik @vholland I am against including OfferCatalog to the range of schema:offers. schema:offers links from products to offers for this product and has a very specific meaning. Its inverse is itemOffered. This is a different branch of schema.org. makesOffer and offeredBy link between an agent and its Offers. itemOffered and offers link between Offers and Products (or Services). Let's not dilute that.

@radusi I would at this point not recommend OfferCatalog for linking from products to their variants.

"makesOffer and offeredBy link between an agent and its Offers. itemOffered and offers link between Offers and Products (or Services). Let's not dilute that."

+1

"I would at this point not recommend OfferCatalog for linking from products to their variants."

Is there a method for 'grouping' nearly similar products?
(eg, products of which only the color differs, or products that are the same but that have different gtin's due to the fact they come from different countries/suppliers).

The reason I ask is because many ecommerce sites have a lot of nearly identical products for which the difference often is limited to a single property value (eg, iPhone 6 Gold vs iPhone 6 Silver).

Reason for a lot of sites to publish things like reviews multiple times for different products, causing there to be tons of duplicate content (which is bad for search) yet providing a lot of value to visitors of a site. After all, the color of a product is hardly a reason why reviews shouldn't be the same for color variants, and makes it easier for people to find relevant reviews without having to look at a ton of different product variants.

A duplicate content problem I think could be resolved if we introduce something like a schema.org/ProductFamily, which could be a list of nearly identical products that share the same reviews (or questions, or descriptions, etc).

I think @jvandriel thought at a page similar to this one http://www.amazon.co.uk/All-New-Kindle-Paperwhite-Resolution-Display/dp/B00QJDO0QC/ [ Wi-Fi +/- Free 3G option ]

I am against including OfferCatalog to the range of schema:offers. schema:offers links from products to offers for this product and has a very specific meaning. Its inverse is itemOffered. This is a different branch of schema.org. makesOffer and offeredBy link between an agent and its Offers. itemOffered and offers link between Offers and Products (or Services). Let's not dilute that.

I have impression that currently schema:Service gets used in two different ways:

1. as Agent/Organization (Agency?) which proposed schema:hasOfferCatalog suggests
   (Organization | Service) - hasOfferCatalog ->OfferCatalog

2. as Product which the other end of the chain suggests
   OfferCatalog - itemListElement -> Offer -> itemOffered -> Service

To my understanding aims at first way of using it, as sort of Agent(Agency?), which IMO could get handled by Organization and makesOffer.

listing multiple Offers loses any sense of hierarchy or categorization of the Offers. For example, it is useful to know a cleaning service offers home vs commercial cleaning without knowing the specific prices of building size or whether carpet cleaning is included.

Does need for such hierarchy only makes sense for Service (used as Product or Agent), or also to Product?

I really think we currently have issue here with Service sometimes wearing Organization hat and sometimes Product hat 😞

Does this one make sense?

Service - hasOfferCatalog ->OfferCatalog - itemListElement -> Offer -> itemOffered
-> Service - hasOfferCatalog ->OfferCatalog - itemListElement -> Offer -> itemOffered -> Service - hasOfferCatalog ->OfferCatalog - itemListElement -> Offer
-> itemOffered -> Service - hasOfferCatalog ->OfferCatalog -
itemListElement -> Offer -> itemOffered -> Service - hasOfferCatalog
->OfferCatalog - itemListElement -> Offer -> itemOffered -> Service etc.