Can we define 'seller' as a subproperty of 'provider' ? (cf noncommercial Offers) #764
Comments
danbri
added
the
schema.org vocab
|
+1 I think authors often do this anyway for the case where seller and provider are the same entity. |
|
👍 |
|
+1 On Fri, Sep 11, 2015 at 10:50 AM, Dan Brickley notifications@github.com
|
|
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. |
|
+1 |
|
@danbri So the included domains of schema:seller currently are:
And the included domains for schema:provider currently are:
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. |
|
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.). |
|
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 |
|
@mfhepp Nice, I like that better. And of course we could also do (and I suspect we would primarily use): -- that would enable us to just swap |
|
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. |
|
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. |
|
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. |
|
You got a point there @mfhepp, |
|
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 ;-) |
|
+1 :) |
|
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. |
|
It is good we are moving away from the implied meaning behind the property In other words, the preferred way of modeling would be Organization or Person -> makesOffer -> Offer -> itemOffered -> Product (or That is great if you enter the graph from the Organization/Person entity. The approach of Product is an elegant solution using JSON-LD. Unfortunately, no matter how much we denigrate Taking the simple elegance of Martin's suggestion but tempering it with a Product This would address the issue without engaging the semantic baggage of what Do we depreciate 'seller' - possibly, but we would need to look into its ~Richard. On Tue, Sep 15, 2015 at 11:55 PM, chaals notifications@github.com wrote:
|
|
@RichardWallis Well, RDFa defines If we do add |
|
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)? |
|
I had a go at a microdata example: But while creating the example I realized that chances of a Which makes me wonder, does it even make sense to try to do this with Something which is much more troublesome for listing pages by the way, as it means that for each |
|
As for the idea of deprecating 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 So IMO the cleanliness of deprecating Is there a special reason why Because if there is/was, wouldn't it then be easier to leave it the way it is, add an inverse property for |
|
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: And the JSON-LD: |
|
Example from the Schemabibex Wiki tweaked to use offeredBy: <!-- 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> |
|
@RichardWallis and I just discussed this. Thinking is to:
|
Add offeredBy property to Offer (#796) plus example Please enter the commit message for your changes. Lines starting
|
In Phobos |
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
The text was updated successfully, but these errors were encountered: