Can we define 'seller' as a subproperty of 'provider' ? (cf noncommercial Offers) #764

Closed
danbri opened this Issue Sep 11, 2015 · 25 comments

Projects

None yet

9 participants

@danbri
Contributor
danbri commented Sep 11, 2015
  • http://schema.org/provider "The service provider, service operator, or service performer; the goods producer. Another party (a seller) may offer those services or goods on behalf of the provider. A provider may also serve as the seller."
  • http://schema.org/seller "An entity which offers (sells / leases / lends / loans) the services / goods. A seller may also be a provider."
  • seller is currently marked as a subproperty of participant (an Action-oriented property)
  • http://schema.org/participant "Other co-agents that participated in the action indirectly. e.g. John wrote a book with Steve."

My motivation here is that I still cringe every time I see 'seller' in non-commercial Offer descriptions, notably library holdings data (#733). Using 'provider' would seem more natural. I'd suggest revising 'seller' description to note that non-commercial offers can be described via 'provider'.

See also #424 #620

/cc @RichardWallis @dbs @vholland @chaals @rvguha @pmika @mfhepp @shankarnat

@danbri danbri self-assigned this Sep 11, 2015
@vholland
Contributor

+1 I think authors often do this anyway for the case where seller and provider are the same entity.

@akuckartz

👍

@RichardWallis
Contributor

+1

On Fri, Sep 11, 2015 at 10:50 AM, Dan Brickley notifications@github.com
wrote:

  • http://schema.org/provider "The service provider, service operator,
    or service performer; the goods producer. Another party (a seller) may
    offer those services or goods on behalf of the provider. A provider may
    also serve as the seller."
  • http://schema.org/seller "An entity which offers (sells / leases /
    lends / loans) the services / goods. A seller may also be a provider."
  • seller is currently marked as a subproperty of participant (an
    Action-oriented property)
  • http://schema.org/participant "Other co-agents that participated in
    the action indirectly. e.g. John wrote a book with Steve."

My motivation here is that I still cringe every time I see 'seller' in
non-commercial Offer descriptions, notably library holdings data (#733
#733). Using 'provider'
would seem more natural. I'd suggest revising 'seller' description to note
that non-commercial offers can be described via 'provider'.

/cc @RichardWallis https://github.com/RichardWallis @dbs
https://github.com/dbs @vholland https://github.com/vholland @chaals
https://github.com/chaals @rvguha https://github.com/rvguha @pmika
https://github.com/pmika @mfhepp https://github.com/mfhepp @shankarnat
https://github.com/shankarnat


Reply to this email directly or view it on GitHub
#764.

@danbri
Contributor
danbri commented Sep 15, 2015

I'd love to know what @dbs thinks about this, as an implementor. The 'seller' variant would remain valid but imho this gives us a path to something that isn't needlessly commercial in its tone.

@erimille

+1

@dbs
Contributor
dbs commented Sep 15, 2015

@danbri So the included domains of schema:seller currently are:

  • BuyAction
  • Demand
  • Flight
  • Offer
  • Order

And the included domains for schema:provider currently are:

  • BusTrip
  • CreativeWork
  • Flight
  • Invoice
  • ParcelDelivery
  • Reservation
  • Service
  • TrainTrip

There's not much overlap (just schema:Flight), and schema:provider isn't even valid on schema:Offer (for some definition of "valid").

Are you suggesting that schema:Offer replace schema:seller with schema:provider, which would then have the option of either taking schema:seller as a more commercially defined subproperty when appropriate? This could lead to a subproperty hierarchy of participant -> provider -> seller, given than seller is already a subproperty of participant, but provider is not.

Or are you suggesting that schema:provider and schema:seller be synchronized to have the same superset of included domains, and directives be given to schema.org consumers (for example, SDTT and associated documentation) that schema:Offer et al should expect either or both of schema:provider and schema:seller properties? Sounds like that would be some fun documentation--heh.

@mfhepp
Contributor
mfhepp commented Sep 15, 2015

Conceptually, I am fine with adding a less commercially names property for linking an organization or person to an offer or demand.

But please note that there is an elegant way of avoiding that route: In GoodRelations, we had the "offers" property to link from the business entity to the offer, which is now "makesOffer" in schema.org.

If we simply foster the use of makesOffer, at least in the non-commercial contexts, and maybe fine-tune the wording a little bit, we should be all set (and we reduce the number of ways for expressing the same thing).

I am also in favor of promoting makesOffer over seller (which comes from pre-GoodRelations times in schema.org) because the latter sounds strange for many business functions (e.g. offering a hotel room for rental, hair cuts, etc.).

@mfhepp
Contributor
mfhepp commented Sep 15, 2015

In other words, the preferred way of modeling would be

Organization or Person -> makesOffer -> Offer -> itemOffered -> Product (or Thing + Product as an MTE)

That is also the essential "Agent-Promise-Object" pattern from GoodRelations,

http://wiki.goodrelations-vocabulary.org/Documentation/Conceptual_model

@dbs
Contributor
dbs commented Sep 15, 2015

@mfhepp Nice, I like that better. And of course we could also do (and I suspect we would primarily use):

Product
    -> offers
       -> Offer
            -> @rev makesOffer
                -> Organization or Person

-- that would enable us to just swap @rev makesOffer in for seller into our existing templates, which would be nice from a lack-of-effort-required solution :)

@mfhepp
Contributor
mfhepp commented Sep 15, 2015

yes, rev will do the trick - in essence, "seller" is one of the hard-wired inverse properties that we might want to deprecate and replace by reverse property mechanisms in the proper syntax.

@jvandriel

eh, I'm all for reverse property mechanisms but as far as I'm aware @itemprop-reverse isn't part of the html5 specs quite yet. Meaning microdata is left behind with this solution.

@mfhepp
Contributor
mfhepp commented Sep 15, 2015

No, you can use makesOffer in the very same way; you are just more constrained in the nesting of elements or have to use global identifiers.

@jvandriel

You got a point there @mfhepp, <link itemprop="makesOffer" href> + global/fragment identifier does the trick as well of course.

@mfhepp
Contributor
mfhepp commented Sep 15, 2015

And anyway, JSON-LD is the new king in town. RDFa will retire and go to the Guggenheim Foundation for its abstract beauty and Microdata to NASA's Houston Space Center for its practical impact ;-)

@jvandriel

+1 :)

@chaals
Contributor
chaals commented Sep 15, 2015

Works for me... (in Russia, we're happy with pencils when they are the right tool for the job).

But I should check with Alex or Yuliya before claiming Yandex is satisfied, given the relatively high amount of microdata in runet.

@RichardWallis
Contributor

It is good we are moving away from the implied meaning behind the property
names such as seller and provider.

In other words, the preferred way of modeling would be

Organization or Person -> makesOffer -> Offer -> itemOffered -> Product (or
Thing + Product as an MTE)

That is great if you enter the graph from the Organization/Person entity.
Unfortunately, especially in worlds such as libraries, the entry point is
often the description of an item/product.

The approach of

Product
-> offers
-> Offer
-> @rev makesOffer
-> Organization or Person

is an elegant solution using JSON-LD.

Unfortunately, no matter how much we denigrate
other serialization approaches, a significant proportion of the adopters of
Schema.org are wedded to Microdata or RDFa. I believe we should probably
over time encourage the the use of the most appropriate serializations and
mark up styles - not to mention the broad support in all areas for JSON-LD
by all partners. That however should be a broad discussion supported by
documentation etc. An individual property, such as we are discussing
here, is not really the forum for such crusading.

Taking the simple elegance of Martin's suggestion but tempering it with a
bit of pragmatism about RDFa, Microdata, and the style of the vocabulary,
leads me to suggest a new property 'offeredBy' with a domain of Offer &
range of Organization & Person - inverse of 'makesOffer'.

Product
-> offers
-> Offer
-> offeredBy "The Person or Organization making the offer"
-> Organization or Person

This would address the issue without engaging the semantic baggage of what
are the meanings of 'seller', 'participant', and 'provider'.

Do we depreciate 'seller' - possibly, but we would need to look into its
other uses first.

~Richard.

On Tue, Sep 15, 2015 at 11:55 PM, chaals notifications@github.com wrote:

Works for me... (in Russia, we're happy with pencils when they are the
right tool for the job).

But I should check with Alex or Yuliya before claiming Yandex is
satisfied, given the relatively high amount of microdata in runet.


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

@dbs
Contributor
dbs commented Sep 16, 2015

@RichardWallis Well, RDFa defines @rev and JSON-LD defines @reverse so it's really only microdata hanging out there with @itemprop-reverse still just being in proposed status that's problematic. But still problematic, yes.

If we do add offeredBy then I hope we can in turn deprecate something rather than continuing to add properties. seller has already superceded merchant and vendor, maybe offeredBy can in turn deprecate seller. Heh!

@danbri
Contributor
danbri commented Sep 16, 2015

Consensus seems to be heading towards a new property. Let's try to make that work.

A note on deprecating 'seller': it is still used in http://schema.org/BuyAction , Flight, Demand, Order where it does actually involve selling

Let's sanity check with a full Microdata + JSON-LD + RDFa example (without using the experimental itemprop-reverse, using #ids, maybe itemref, in the microdata)?

@jvandriel

I had a go at a microdata example:

<body itemid="http://www.example.com/explosive-tennis-balls" itemscope itemtype="http://schema.org/ItemPage" itemref="CopyrightYear">
  <link itemprop="copyrightHolder publisher" href="#Organization" />
  <main>
    <article itemid="#Product" itemprop="mainEntity" itemscope itemtype="http://schema.org/Product">
      <h1 itemprop="name">
         <a itemprop="url" href="http://www.example.com/explosive-tennis-balls">Explosive tennis balls</a>
      </h1>     
      <img itemprop="image" alt="Explosive tennis balls" title src="http://www.example.com/explosive-tennis-balls.jpg" />
      <p itemid="#Offer" itemprop="offers" itemscope itemtype="http://schema.org/Offer">
        <meta itemprop="priceCurrency" content="USD" />
        <meta itemprop="price" content="1000.00" />
        <link itemprop="availability" href="http://schema.org/InStock" />
        <link itemprop="itemOffered" href="#Product" />
        <link itemprop="businessFunction" href="http://purl.org/goodrelations/v1#Sell" />
        $29.99 - In stock
      </p>
      <p itemprop="description">
        Tickle your friends!<br />
        Surprise your opponent!
      <p>
    </article>
  </main>
  <footer>
    <p itemid="#Organization" itemscope itemtype="http://schema.org/Organization" itemref="SameAsResource">
      © <span itemscope><span id="CopyrightYear" itemprop="copyrightYear">2015</span></span> - <span itemprop="name">Acme Inc</span>
      <link itemprop="logo" href="http://www.example.com/acme-inc-logo.jpg" />
      <link itemprop="url" href="http://www.example.com" />
      <link itemprop="makesOffer" href="#Offer" />
    </p>
    <div itemscope>
      <ul id="SameAsResource">
        <li><a itemprop="sameAs" href="https://twitter.com/AcmeInc">Twitter</a></li>
        <li><a itemprop="sameAs" href="https://www.facebook.com/AcmeInc">Facebook</a></li>
        <li><a itemprop="sameAs" href="https://plus.google.com/u/0/+AcmeInc/">Google+</a></li>
      </ul>
    </div>
  </footer>
</body>

But while creating the example I realized that chances of a schema.org/Offer ever being nested within a schema.org/Organization are extremly slim (looking at current popular page templates), thus making it very unlikely schema.org/Organization is candidate for getting modelled as the top level entity so to make a makesOffer relation possible. For example, the type of HTML I used in this example is what I've encountered during most of my work for (ecommerce) sites.

Which makes me wonder, does it even make sense to try to do this with makesOffer in microdata?
Organization data contained in a footer is a very bad place to have to add such data to. Most of the time its template isn't part of the same template files that are used for the main content?

Something which is much more troublesome for listing pages by the way, as it means that for each schema.org/Offer an extra <link itemprop="makeOffer" href="#..." /> needs to be added to the schema.org/Organization. Something you can't work around via @itemref either as that means there has to be an unique @id value for each schema.org/Offer instead.

@jvandriel

As for the idea of deprecating seller, I'm not sure I'm to crazy about that. Not that it isn't nice from a vocabulary POV, after all, it keeps things nice and clean - but IMHO seller is a property people, that are not that familiar with schema.org yet, probably look for when searching for ways to express what they have in mind. In large part due to the fact that modelling the graph from a schema.org/Product perspective has been thé promoted method for doing this and thus the web is full of examples on how to model this.

Product
  offer > Offer
    seller > Organization

Especially as many still look at the order of the DOM for structuring their data. A method I feel doesn't make it very likely people will start referring to offers made by the organization by means of makesOffer when they make use of microdata (unless @itemprop-reverse gets added to the html5 specs).

So IMO the cleanliness of deprecating seller doesn't outway the likely difficulties this will create for those having to add/maintain markup for CMS templates containing microdata (or even static pages for that matter).

Is there a special reason why provider hasn't been added to schema.org/Offer earlier on already by the way?

Because if there is/was, wouldn't it then be easier to leave it the way it is, add an inverse property for makesOffer, namely offeredBy (like @RichardWallis suggested) and have seller be a subproperty of that?

Product
  offers > Offer
    offeredBy > Organization
@jvandriel

Anyways, here's the RDFa version (Be aware the validators provided by Google and Yandex don't seem to be able to deal with rdfa:copy + rdfa:pattern. The structured data linter and RDFa Play do however:

<body vocab="http://schema.org/" resource="http://www.example.com/explosive-tennis-balls" typeof="ItemPage">
  <link property="copyrightHolder publisher" href="#Organization" />
  <link property="rdfa:copy" href="#CopyrightYear" />
  <main>
    <article resource="#Product" property="mainEntity" typeof="Product">
      <h1 property="name">
         <a property="url" href="http://www.example.com/explosive-tennis-balls">Explosive tennis balls</a>
      </h1>     
      <img property="image" alt="Explosive tennis balls" title src="http://www.example.com/explosive-tennis-balls.jpg" />
      <p resource="#Offer" property="offers" typeof="Offer">
        <meta property="priceCurrency" content="USD" />
        <meta property="price" content="1000.00" />
        <link property="availability" href="InStock" />
        <link property="itemOffered" href="#Product" />
        <link property="businessFunction" href="http://purl.org/goodrelations/v1#Sell" />
        <link rev="makesOffer" href="#Organization" />
        $29.99 - In stock
      </p>
      <p property="description">
        Tickle your friends!<br />
        Surprise your opponent!
      <p>
    </article>
  </main>
  <footer>
    <p resource="#Organization" typeof="Organization">
      © <span resource="#CopyrightYear" typeof="rdfa:Pattern">2015</span> - <span property="name">Acme Inc</span>
      <link property="logo" href="http://www.example.com/acme-inc-logo.jpg" />
      <link property="url" href="http://www.example.com" />
      <link property="rdfa:copy" href="#SameAsResource"/>
    </p>
    <ul resource="#SameAsResource" typeof="rdfa:Pattern">
      <li><a property="sameAs" href="https://twitter.com/AcmeInc">Twitter</a></li>
      <li><a property="sameAs" href="https://www.facebook.com/AcmeInc">Facebook</a></li>
      <li><a property="sameAs" href="https://plus.google.com/u/0/+AcmeInc/">Google+</a></li>
    </ul>
  </footer>
</body>

And the JSON-LD:

<script type="application/ld+json">
{
  "@context":"http://schema.org",
  "@id":"http://www.example.com/explosive-tennis-balls",
  "@type":"ItemPage",
  "copyrightYear":"2015",
  "copyrightHolder":{"@id":"#Organization"},
  "publisher":{"@id":"#Organization"},
  "mainEntity":{
    "@id":"#Product",
    "@type":"Product",
    "name":"Explosive tennis balls",
    "description":"Tickle your friends! Surprise your opponent!",
    "image":"http://www.example.com/explosive-tennis-balls.jpg",
    "url":"http://www.example.com/explosive-tennis-balls",
    "offers":{
      "@id":"#Offer",
      "@type":"Offer",
      "priceCurrency":"USD",
      "price":"1000.00",
      "availability":"http://schema.org/InStock",
      "itemOffered":{"@id":"#Product"},
      "businessFunction":"http://purl.org/goodrelations/v1#Sell",
      "@reverse":{
        "makesOffer":{
          "@id":"#Organization",
          "@type":"Organization",
          "name":"Acme Inc",
          "logo":"http://www.example.com/acme-inc-logo.jpg",
          "url":"http://www.example.com/",
          "sameAs":["https://twitter.com/AcmeInc","https://www.facebook.com/AcmeInc","https://plus.google.com/u/0/+AcmeInc/"]
        }
      }      
    }
  }
}
</script>
@RichardWallis
Contributor

Example from the Schemabibex Wiki tweaked to use offeredBy:
RDFa

 <!-- Uses both the "Book" and "Product" item types to support Offer relationships -->
 <div vocab="http://schema.org/" resource="#record" typeof="Book Product">
   <h3 property="name">Le concerto</h3>
   <table summary="Bibliographic Details">
     <tr>
       <th>Main Author: </th>
       <td property="author">Ferchault, Guy</td>
     </tr>
   </table>
 </div>

 <table vocab="http://schema.org/" summary="Holdings details from Anytown City Library">
   <!-- Example of a copy available for loan -->
   <tr typeof="Offer">
     <th>Copy </th>
     <td>Available
       <link property="availability" href="http://schema.org/InStock">
       <div>Barcode: <span property="serialNumber">CONC91000937</span></div>
       <div>Call number: <span property="sku">780 R2</span></div>
       <div>Library: <span property="offeredBy" typeof="Library" resource="http://library.anytown.gov.uk" >Anytown City Library</span></div>
       <link property="businessFunction" href="http://purl.org/goodrelations/v1#LeaseOut">
       <link property="itemOffered" href="#record">
     </td>
   </tr>
 <table>

Microdata

 <!-- Uses both the "Book" and "Product" item types to support Offer relationships -->

 <div itemscope itemtype="http://schema.org/Book" itemid="#record">
   <link itemprop="additionalType" href="http://schema.org/Product"/>
   <h3 itemprop="name">Le concerto</h3>
   <table summary="Bibliographic Details">
     <tr>
       <th>Main Author: </th>
       <td itemprop="author">Ferchault, Guy</td>
     </tr>
   </table>
 </div>

 <table summary="Holdings details from Anytown City Library">
   <!-- Example of a copy available for loan -->
   <tr itemscope itemtype="http://schema.org/Offer">
     <th>Copy </th>
     <td>Available
       <link itemprop="availability" href="http://schema.org/InStock">
       <div>Barcode: <span itemprop="serialNumber">CONC91000937</span></div>
       <div>Call number: <span itemprop="sku">780 R2</span></div>
       <div>Library: <span itemprop="offeredBy" itemtype="http://schema.org/Library" itemid="http://library.anytown.gov.uk" >Anytown City Library</span></div>
       <link itemprop="businessFunction" href="http://purl.org/goodrelations/v1#LeaseOut">
       <link itemprop="itemOffered" href="#record">
     </td>
   </tr>
 <table>

JSONLD

<script type="application/ld+json">
{
  "@context": {
    "rdf": "http://www.w3.org/1999/02/22-rdf-syntax-ns#",
    "rdfa": "http://www.w3.org/ns/rdfa#",
    "rdfs": "http://www.w3.org/2000/01/rdf-schema#",
    "schema": "http://schema.org/",
    "xsd": "http://www.w3.org/2001/XMLSchema#"
  },
  "@graph": [
    {
      "@id": "#record",
      "@type": ["schema:Book","schema:Product"],
      "schema:name": "Le concerto",
      "schema:author": "Ferchault, Guy"
    },
    {
      "@type": "schema:Offer",
      "schema:availability": "http://schema.org/InStock",
      "schema:serialNumber": "CONC91000937",
      "schema:sku": "780 R2",
      "schema:offeredBy": {
          "@type": "schema:Library",
          "@id": "http://library.anytown.gov.uk",
          "schema:name": "Anytown City Library"
      },
      "schema:businessFunction": "http://purl.org/goodrelations/v1#LeaseOut",
      "schema:itemOffered": "#record"
    }
]
}
</script>
@danbri danbri assigned RichardWallis and unassigned danbri Sep 25, 2015
@danbri
Contributor
danbri commented Sep 25, 2015

@RichardWallis and I just discussed this. Thinking is to:

  • use examples w/ the existing property http://schema.org/makesOffer
  • do the best we can in microdata for now
  • adopt this idiom for the #733 Library / Book holdings examples /cc @dbs
  • open another issue for a convenience inverse, offeredBy
@RichardWallis RichardWallis added a commit that referenced this issue Sep 25, 2015
@RichardWallis RichardWallis Example for makesOffer (#764)
Add offeredBy property to Offer (#796) plus example
Please enter the commit message for your changes. Lines starting
dc1b58f
@RichardWallis RichardWallis added a commit that referenced this issue Sep 25, 2015
@RichardWallis RichardWallis (#796) (#764) eb916c8
@RichardWallis
Contributor

In Phobos

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