-
Notifications
You must be signed in to change notification settings - Fork 835
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create subtype of ItemList for OfferCatalog #818
Comments
Created pull request #821. |
Just to make sure I get this right @vholland, do you mean this type would be the preferred type for a product listing page? |
@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. |
"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 |
I'll merge this into sdo-phobos to aid with reviewing it - easier to understand in context vs reading config file markup I think. |
Issue #818: Added OfferCatalog and hasOfferCatalog.
FYI: http://sdo-phobos.appspot.com/OfferCatalog - queued for final review |
I'm still struggling to understand what type of page you imagine using And why the sudden change from modeling such data from a 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. |
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 :) |
There are multiple threads across various pull requests and issues. Trying to tie together:
Implementation should be discussed in issue #827 so people know what they are signing off on. |
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. |
+1 to the current proposal with using makesOffer to link an Organization to an OfferCatalog and changing hasOfferCatalog to serviceDetails. |
+1 to the proposal by @vholland |
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... |
OfferCatalog to the range for makesOffer.
#843 looks good to me. |
Sorry, I am not ok with renaming hasOfferCatalog to serviceDetails. hasOfferCatalog has a simple clear unambiguous meaning and people will use guha On Tue, Oct 13, 2015 at 10:44 AM, Martin Hepp notifications@github.com
|
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
|
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
|
👍 Organization (agent) offers services, not a Service offers services 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 |
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. |
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? |
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
|
@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. |
At first glance I thought I'd prefer So +1 for |
@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. |
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 |
@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. |
As I read the thread, we have agreed that http://schema.org/Service will have the property The remaining discussion is whether Person and Organization should also have As @danbri suggested, a series of Something like:
I suggest we:
|
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. |
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). |
@jvandriel do you find @vholland 's example markup above too idealized? |
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. Agent - makesOffer -> Offer Service - offers -> Offer 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). |
@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. |
@vholland @danbri @rvguha
IF ?a rdf:type schema:Person OR schema:Organization ?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 |
@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.
This doesn't seem to account for possible additional schema:ListItem indirection: Agent - hasOfferCatalog -> OfferCatalog - itemListElement -> ListItem - item -> Offer |
…nd expanded the example as listed in the discussion.
I made the changes in pull request #852 |
"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. |
…ling. Per #818 this should work for non-profit use cases too e.g. library books.
OK I've updated the test build from http://sdo-phobos.appspot.com/hasOfferCatalog please take a look. Wrap-up points (implemented already):
I believe both of these are addressed with the following tweak. New and hopefully final text is:
|
+1 martin hepp |
…ase review. We were generating HTML with markup inside it. Migrated to using first non-markup sentence. /cc @RichardWallis.
@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. |
@vholland - thanks. I realised it was there when I published the build. I think we're fine now. |
Fixed in http://schema.org/docs/releases.html#v2.2 - thanks all |
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.
The text was updated successfully, but these errors were encountered: