Create subtype of ItemList for OfferCatalog #818

Closed
vholland opened this Issue Oct 1, 2015 · 45 comments

Projects

None yet

7 participants

@vholland
Contributor
vholland commented Oct 1, 2015

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 vholland self-assigned this Oct 1, 2015
@vholland vholland added this to the sdo-phobos release milestone Oct 1, 2015
@vholland vholland added a commit to vholland/schemaorg that referenced this issue Oct 1, 2015
@vholland vholland Issue #818: Added OfferCatalog and hasOfferCatalog. c47cfca
@vholland
Contributor
vholland commented Oct 1, 2015

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
Contributor
vholland commented Oct 1, 2015

@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
Contributor
danbri commented Oct 1, 2015

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
Contributor
danbri commented Oct 2, 2015

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.

@vholland vholland referenced this issue Oct 2, 2015
Closed

Meta bug for sdo-phobos release (as v2.2) #827

5 of 5 tasks complete
@danbri
Contributor
danbri commented Oct 2, 2015

I've opened an issue #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
Contributor
vholland commented Oct 5, 2015

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
Contributor
danbri commented Oct 7, 2015

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
Contributor
mfhepp commented Oct 8, 2015

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

@danbri
Contributor
danbri commented Oct 9, 2015

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

@shankarnat
Contributor

+1 to the proposal by @vholland

@danbri
Contributor
danbri commented Oct 12, 2015

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 vholland added a commit to vholland/schemaorg that referenced this issue Oct 13, 2015
@vholland vholland Issue #818: Changed hasOfferCatalog to serviceDetails and added
OfferCatalog to the range for makesOffer.
10daee9
@vholland
Contributor

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

@mfhepp
Contributor
mfhepp commented Oct 13, 2015

#843 looks good to me.
+1

@rvguha
Contributor
rvguha commented Oct 13, 2015

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 #843 looks good to me.
+1


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

@mfhepp
Contributor
mfhepp commented Oct 14, 2015

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 #843 looks good to me.
+1


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


Reply to this email directly or view it on GitHub.

@rvguha
Contributor
rvguha commented Oct 14, 2015

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 #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
#818 (comment)
.

@elf-pavlik
Contributor

A business organization should be able to have a service catalog

👍 Organization (agent) offers services, not a Service offers services
#821 (comment)

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
Contributor
danbri commented Oct 21, 2015

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
Contributor

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
Contributor
mfhepp commented Oct 21, 2015

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
Contributor
rvguha commented Oct 21, 2015

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
#818 (comment)
.

@mfhepp
Contributor
mfhepp commented Oct 22, 2015

@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
Contributor
danbri commented Oct 22, 2015

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

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 w3c/activitystreams#191

@danbri
Contributor
danbri commented Oct 23, 2015

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

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
Contributor
danbri commented Oct 27, 2015

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
Contributor
danbri commented Oct 27, 2015

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

@elf-pavlik
Contributor
  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
Contributor

@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
Contributor
mfhepp commented Oct 27, 2015

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

@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 vholland added a commit to vholland/schemaorg that referenced this issue Oct 27, 2015
@vholland vholland Issue #818: Added Person to the domain for hasOfferCatalog and expanded
the example as listed in the discussion.
ecfb19c
@vholland
Contributor

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
Contributor
danbri commented Oct 27, 2015

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 danbri pushed a commit that referenced this issue Oct 28, 2015
Dan Brickley Explicitly tied semantics to offeredBy, and removed assumption of sel…
…ling.

Per #818 this should work for non-profit use cases too e.g. library books.
8e744cc
@danbri
Contributor
danbri commented Oct 28, 2015

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
Contributor
mfhepp commented Oct 28, 2015

+1


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

@danbri danbri pushed a commit that referenced this issue Oct 28, 2015
Dan Brickley Fixed HTML generation bug reported by @mfhepp in #818 sdo-phobos rele…
…ase review.

We were generating HTML with markup inside it. Migrated to using first non-markup
sentence. /cc @RichardWallis.
435de82
@vholland
Contributor

@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
Contributor
danbri commented Oct 28, 2015

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

@danbri
Contributor
danbri commented Nov 6, 2015
@danbri danbri closed this Nov 6, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment