Open nickevansuk opened 4 years ago
Just highlighting an inconsistency with the above proposal:
One advantage of"bookingService"
is that it is the name of the product, rather than the organisation. For example Gladstone Ltd have a number of products, including Gladstone360 and GladstoneOne, and their values for bookingService
would be as follows:
"bookingService": {
"@type": "BookingService",
"name": "Gladstone360",
"softwareVersion": "2.0",
"url": "https://www.gladstonesoftware.co.uk/platform-overview"
},
"bookingService": {
"@type": "BookingService",
"name": "GladstoneOne",
"softwareVersion": "2.0",
"url": "https://www.gladstonesoftware.co.uk/single-site"
},
This also works well in terms of any conformance certificate - as it is necessarily the product that gets the conformance certificate, rather than the organisation.
Additionally the publisher
is not the bookingService
, or even the organisation that owns the bookingService
, in the case of Gladstone above - the publisher
is the actual leisure operator.
On reflection, perhaps it's best that we stick with the original proposal (which just uses publisher
as whichever or is responsible for publishing - which might be the booking system owner, or the activity provider, depending on the technology in use), and keep bookingService
as the technology being used to publish (and for which schema.org does not currently include a term).
Additionally perhaps BookingService
should subclass schema:Product
, to make it clear that this relates to the product rather than the organisation
Discussed on W3C call of 2020-09-09. Agree to retain current implementation.
There's conflicting language being used here: BookingService
is a product? Should we use a better name here?
Actually, aren't we really talking about a schema.org SoftwareApplication
?
I would then suggest in relation to #15 that what we really want is FeatureList
, which has the description "Features or modules provided by this application (and possibly required by other applications)", and is typed as Text
or URL
.
Yes, great idea! Additionally WebApplication
is a subclass of SoftwareApplication
, so this should work even when the application is entirely web-based (e.g. "Playwaze").
I did look at FeatureList
, however it doesn't reference a schema.org type, so doesn't allow for structured data within it...
Sorry, was reflecting on conformsTo
and edited the above while you were posting. I think we really want featureList
, as (now) noted above.
Ha, no worries, I edited mine to match :)
Sorry, wasn't clear. I was referring to featureList
in relation to #15. So, something like:
{
"@type" : "SoftwareApplication",
"name": "GladstoneOne",
"softwareVersion": "2.0",
"url": "https://www.gladstonesoftware.co.uk/single-site",
"featureList": [
""https://openactive.io/openactive-test-suite/example-output/controlled/certification/"
]
}
Formalised in 0.2 as in the example immediately above. For discussion.
The discussion in the W3C Community Group call on 13 January 2021, taking inspiration from the WebAPI discussions, concluded that one evolution of the above could be to use CreativeWork
(or a subclass of CreativeWork
) within featureList
.
Looking at this further, and given that it is difficult for us to add to the range to existing schema.org properties (we avoid doing so where possible), perhaps defining a new property within SoftwareApplication
would be the best approach?
Using the pattern of softwareHelp
, which has a range of CreativeWork
, perhaps this could look like:
"bookingService": {
"@type" : "SoftwareApplication",
"name": "GladstoneOne",
"softwareVersion": "2.0",
"url": "https://www.gladstonesoftware.co.uk/single-site",
"hasConformanceCertificate": [
{
"@type": "CreativeWork",
"encodingFormat": "application/vnd.openactive.certification+json",
"url": "https://openactive.io/openactive-test-suite/example-output/controlled/certification/"
}
]
}
Advantages:
Disadvantages:
bookingService
is already an oa:
custom property, this would be the case anyway.Another comparison for the above: hasConformanceCertificate
is similar to hasCredential
, which already has a range of EducationalOccupationalCredential
(which in turn subclasses CreativeWork
)
Problem
We need to align how we're representing organizations that are related to a dataset with Google's expectations for the purposes of SEO.
The current draft data model for Dataset API Discovery includes:
bookingService
is a property in the OpenActive namespace, and is not recognised by Google. It is also not clear whether thepublisher
property is being used correctly in this context.Considerations
Google's Structured Data Documentation
Google's Structured Data Documentation recommends the use of the property
creator
to represent the "The creator or author of this dataset", and does not provide specific references for other properties (though points to schema.org for more information).schema.org
schema.org includes several options for attibution of the roles of organizations relating to a schema:Dataset:
creator
- The creator/author of this CreativeWorkmaintainer
- A maintainer of a Datasetpublisher
- The publisher of the creative work.sourceOrganization
Existing OpenActive dataset sites
The dataset site text reads:
Note that single database systems generally set
bookingService
to matchpublisher
, as they are the same.Proposal
Note this proposal doesn't consider
maintainer
, which could be useful to include within the JSON-LD as a duplicate ofcreator
(if set)?Multiple database systems
For multiple database systems, where there is one dataset site per activity provider:
creator
- The activity providerpublisher
- The booking systemSingle database systems
For single database systems, where there is one dataset site that contains data from multiple activity providers:
publisher
- The booking system(Note in this proposal the "Platform" reference is removed from the HTML for Single database systems)
Implementation note
We need to ensure the embedded DCAT markup reflects this change.