The Automotive Ontology Working Group is an informal group of individuals and corporations who want to advance the use of shared conceptual structures in the form of Web ontologies for better data interoperability in the automotive industry, and this at Web scale. In particular, we want to develop
extension proposals for schema.org so that automotive information can be better understood by search engines and
OWL Web ontologies for the automotive industry.
Also, we want to provide a forum for bringing together researchers and practitioners who are working on advancing the field.
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
It comes a bit later than I expected, nonetheless I’m happy to inform you that as the results of our discussions here we are now proposing the following changes to schema.org types and properties related to our automotive extension:
Description for http://auto.schema.org/emissionsCO2 has been changed, because there is no UN/CEFACT Common Code for g/km.Before: ‘The CO2 emissions in g/km. The property uses a number instead of a QuantitativeValue, since g/km is the dominant unit of measurement, and there is no UNCEFACT Common Code for g/km.’After: ‘The CO2 emissions in g/km. When used in combination with a QuantitativeValue, put “g/km” into the unitText property of that value, since there is no UN/CEFACT Common Code for “g/km”.’
The text “This should be considered a pre-final preview release; final changes may be made after wider community review.” has been removed from the extension home page.
There is also an issue being discussed on the GitHub whether http://schema.org/vehicleSpecialUsage should be in the core or in the extension. As soon as this is resolved and some errors related to this property range and domain, we will lunch the Pull Request that will end this phase of Community review.
We came to the end of the review process. There were few changes proposed, and after some discussion we have one change to make (thanks to Tom Adamich):
Broaden the range of emmisionsCO2 property.
We suggest adding QuantitativeValue to the range of emmisionsCO2 property. One could then use “name” or “valueReference” to relate to test protocols or standards. This change also requires modification of property description.
We will now proceed to get this change accepted and activated !
To help with the review we just launched, please find a simple indented list of all terms in auto.schema.org.
We use red color for types, turquoise for individua and default color for properties.
All terms are hyperlinks to respective auto.schema.org description.
Please find some important remarks and a technical guidance about the initial phase of works on GAO. Feel free to comment on that matters – our goal is to create the process that is not too complicated and assumes use of simple tools (at least in the beginning)
1. Some ontological remarks
We start building GAO from collecting the concepts recognised as relevant within the automotive domain.
The concepts will be collected in a conceptual map called „bag-of-concepts”. Adding the new concepts to the conceptual map, we can take advantage of the auto.schema.org or go beyond the set of concepts we have there. The first set of concepts is stored in GAO.mm file.
By the collaborative development we shall create the conceptualisation of the automotive domain shared by all the participants of Automotive Ontology Community Group.
At this stage of GAO development process we shall not impose any semantical structure on the bag-of-concepts. The concepts are to be loosely linked by one relation which covers all the SKOS-like hierarchical and associative relations such as “broader”, “narrower” and “(somehow) related”.
Of course, in the end, GAO is intended to be a formal specification (RDF(S) or OWL) of the conceptualisation of the automotive domain (shared by all the participants of Automotive Ontology Community Group). So just after the community decides the work on the conceptual map of the domain was completed, we shall transform the bag-of-concepts into the first version of GAO
2. A brief technical guidance
At this stage to contribute to GAO it is enough to have the most up-to-date conceptual map of GAO concepts represented by the mind mapping diagram (see GAO.mm file). The GAO.mm file can be easily modified by FreeMind tool (available here: http://freemind.sourceforge.net/wiki/index.php/Download).
Our first community group conference call was convened on Thursday July 30, 12 PM EDT. We had about 10 participants.
After a brief introduction of all participants we have discussed the following matters:
The current status of schema.org automotive vocabularies, both in the core (schema.org) and in the forthcoming extension (auto.schema.org)
The planned deliveries after the first
The potential change of the work plan to include brainstorming as the first step to build the initial “bag-of-concepts” that, together with concepts we already have in schema.org, will form the seed for GAO vocabulary.
The use of GitHub as the collaborative tool for our common development.
The use of FreeMind as the supporting tool for brainstorming.
Referring to matters (1) and (2) Martin Hepp explained that while we can propose some modifications to schema.org automotive vocabularies, particularly to the forthcoming auto.schema.org extensions, we should not make revolutionary changes. Both core and auto.schema.org are reviewed extensions and there is always a risk of long review processes and a danger promoting terms that are not important from global search engines perspectives. Martin also explained that more manufacturer specific terms can us schema.org Property-Value (https://schema.org/PropertyValue) mechanism.
The rest of the call was devoted to the plans to introduce brainstorming process as a first step in going beyond the set of terms we have in schema.org. In that context, the use of “mind mapping” diagrams was recommended as they do not presuppose any specific kind of relation (like is_a relation) in the initial collection process.
The use of FreeMind tool (available here) has been proposed.
The initial diagrams for schema.org vocabularies and first attempt to create a bag of concepts for GAO were presented.
The current content of the two GitHub repositories:
is limited to Freemind native files (‘mm’ extension)
The next call is planned after summer holidays in September. Meanwhile the practical methods of building the set of terms will be proposed by us so that we can start fully productive activity after the next call.
The diagrams presented during the call:
1) Current schema.org core set of terms:
2) Proposed (awaiting publication) auto.schema.org set of terms:
(Note: there are some small difference between the diagram and current proposal)
3) The first trial set of terms for GAO brainstorming:
We had a very nice and informative first Community Group Conference call last week (The summary is coming here soon).
One of the results of the call is that we agreed to use GitHub as our repository of electronic materials, source code, future ontology files etc.
Our profile is https://github.com/W3C-GAO and has been temporarily assigned to the email account email@example.com (until we practically figure out how to use our internal w3.org email facility of this group for such purposes).
Both contain source files for FreeMind tool (available here) that we will use for sketching the structure and content of our vocabularies as the initial tool for brainstorming. I will shortly describe it all in the call summary.
Anyone from this community group who plans to contribute to the development (all are warmly welcomed) please send the respective request to me (firstname.lastname@example.org).
The aim of the W3C Automotive Ontology Community Group is facilitate the development of web ontologies that define and describe the shared conceptual structures in the automotive industry. The first step in this development, the automotive extension proposal for schema.org is now in the process of finalization – the most important properties and classes have become the part of schema.org 2.0 core on May 13, 2015. The finalization of the auto.schema.org (“reviewed/hosted”) extension is expected very soon. The scope of the first set of concepts, those in core and in the auto.schema.org includes terms that describes vehicles from the sales or automotive market perspective.
Using this baseline scope, the community group intends to grow the automotive ontologies both horizontally – by adding new important types and properties related to the market perception of autos, essentially amending the auto.schema.org, and vertically – by adding other types and properties describing other aspects of cars, such as vehicle configuration and “buildability” aspect, vehicle lifetime aspects, or vehicle data backbone aspects – covering the new realities of “connected cars”, autonomous cars etc.
The open source ontology (or ontologies) to be developed, have inherited the code name GAO – Generic Automotive Ontology (and its URI: http://purl.org/gao) from the informal group of individuals and corporations that worked on it since the fall of 2013.
The ontologies developed in this work may be voted on by its members to be included into future evolutions of auto.schema.org extension, external extensions or become subject of standardization efforts with relevant standardization bodies.
The solutions developed in this group may be voted on by its membership via decision-making approaches described by W3C, IETF, or similar standardization bodies.
The charter can be revised by the consensus of the Community Group. The key considerations are:
The overall goal of GAO, including the selection and balance between initially proposed aspects of automotive industry to be reflected in GAO ontologies.
The scope of work
Deliveries and roadmap
Dependencies and liaisons
Community Group processes (including tools)
Overall goals of GAO
The fundamental goal of the GAO ontology (or family of ontologies) is to create a common conceptual framework for information sharing and data exchange for the benefit of the automotive industry and the benefit of industries related to the automotive industry, including but not limited to: insurance industry, media and marketing industry, transportation infrastructure industry (road systems) etc.
To achieve this goal the community will:
Clearly define the key components of GAO, initially including:
a) GAO Compatibility: A schema.org-compliant ontology for vehicle configuration information.
b) GAO Vehicle Lifetime Information: A schema.org-compliant ontology for vehicle life-time information.
c) GAO Vehicle Data Backbone: An ontology for information interchange within a vehicle, between vehicles, and between vehicles and their external entities. The community may propose different set of key components for GAO or add new components.
Collect and describe the use cases of the GAO ontologies
Review the existing schema.org extensions (core and auto.schema.org)
Review existing standards, publically available taxonomies and vocabularies
Propose the amendment of auto.schema.org
Build the prototypes of respective GAO ontologies
Submit the proposals of subsets of respective GAO ontologies to auto.schema.org extension.
Develop materials describing the ontologies
Develop set of implementation recommendations for future users of GAO ontologies
Identify opportunities for creating broad adoption of GAO ontologies
Engage the developer community to use GAO ontologies in the software
The following initial roadmap has been envisioned and shall be discussed in the first community group teleconferences. This roadmap contains milestones from the work inception to the delivery of GAO prototypes, and covers time span from July 2015 to March 2016. The further works will be defined at the end of this period.
The first teleconference – initial plan for week 31 (July 27-31, 2015) – final details to be agreed
Review of existing schema.org extensions – September 2015
Review of existing standards – September 2015
Definition of the key components of GAO – October 2015
Collection of GAO use cases – November 2015
Creation of the first GAO prototypes – February 2016
Creation of the final report – March 2016
Scope of Work
This section contains a brief overview of the works planned in the roadmap
Review of the existing schema.org extension
The team that proposed the existing schema.org extension, with possible participation of the schema.org team members will present the existing extension, their motivations and decisions and will open the discussion about the potential changes and additions to the extension. As the result of these actions, an amendment proposal may be presented by the community to the schema.org team.
Review of existing standards
The members of the community will present existing standards related to scope of GAO. The standards may include but will not be limited to lexicons of standards like ISO-10303 STEP AP 214, existing ontologies like Vehicle Sales Ontology – VSO , Car Options Ontology – COO, Volkswagen Vehicle Ontology – VVO, Used Cars Ontology – UCO or ‘Configuration as Linked Data’ ontology etc. To broaden the scope of existing standards the community members will appoint the other known standards and ontologies relevant for GAO.
Definition of the key components of GAO
The community will discuss and decide about the scope of the component of GAO ontologies. The ideas underlying the initially proposed components (described in this document in the “Overall Goals of GAO” section 1.a-c) will be discussed and agreed upon or modified. Possible other components will be added.
Collection of GAO use cases
The community members will collect the real and possible use cases of GAO ontologies. The real use cases may contain existing implementations of schema.org extensions developed in the framework of GAO. The future use cases will form a kind of “thought experiments” helping to shape the GAO components.
Creation of the first GAO prototypes
Selected community members of some appointed third party will build GAO prototypes (as OWL ontologies, serialized as Turtle and JSON-LD) accompanied by appropriate visualizations to help in the presentation of the prototypes. For schema.org extension amendments the canonical representation will be used (RDFa).
The final report of the currently planned works will be created and submitted by the community group chair and submitted to W3C after all corrections and community-wide discussion.
The intention of GAO community is to continue the work beyond GAO prototypes. The respective new goals and the scope of work will be formulated after the final report submission.
Dependencies or Liaisons
We have identified the following projects/initiatives relevant to the scope of GAO:
W3C Automotive Working Group, which mission is to develop Open Web Platform specifications for developers writing applications for in-vehicle infotainment systems and vehicle data access protocols.
Automotive and Web Platform Business Group, which mission is to influence the Open Web Platform on the unique needs of the automotive industry, and to help stakeholders within the automotive industry to build a good and practical understanding on the standardization processes within the W3C.
AutoAlliance, The Alliance of Automobile Manufacturers (Auto Alliance) calls itself “the voice for a united auto industry”. They promote sustainable mobility and benefit society in the areas of environment, energy and motor vehicle safety.
Automotive Industry Action Group – AIAG – is a not-for-profit association where professionals from a diverse group of stakeholders – including retailers, suppliers of all sizes, automakers, manufacturers, service providers, academia, and government – work collaboratively to streamline industry processes via global standards development & harmonized business practices.
The European Automobile Manufacturers’ Association – ACEA – represents the 15 Europe-based car, van, truck and bus makers. ACEA works with a variety of institutional, non-governmental, research and civil society partners – as well as with a number of industry associations with related interests.
Anything in this charter that conflicts with requirements of the Community and Business Group Process is void.
Choosing a Chair
This group chooses their Chair(s) and can replace the Chair(s) at any time using whatever means they prefer. However, if 5 participants – no two from the same organization – call for an election, the group must use the following process to replace any current Chair(s) with a new Chair, consulting the Community Development Lead on election operations (e.g., voting infrastructure and using RFC 2777).
Participants announce their candidacies. Participants have 14 days to announce their candidacies, but this period ends as soon as all participants have announced their intentions. If there is only one candidate, that person becomes the Chair. If there are two or more candidates, there is a vote. Otherwise, nothing changes.
Participants vote. Participants have 21 days to vote for a single candidate, but this period ends as soon as all participants have voted. The individual who receives the most votes – no two from the same organization – is elected chair. In case of a tie, RFC2777 is used to break the tie. An elected Chair may appoint co-Chairs.
Participants dissatisfied with the outcome of an election may ask the Community Development Lead to intervene. The Community Development Lead, after evaluating the election, may take any action including no action.
This group will seek to make decisions when there is consensus. When the group discusses an issue on the mailing list and there is a call from the group for assessing consensus, after due consideration of different opinions, the Chair should record a decision and any objections.
Participants may call for an online vote if they feel the Chair has not accurately determined the consensus of the group or if the Chair refuses to assess consensus. The call for a vote must specify the duration of the vote which must be at least 7 days and should be no more than 14 days. The Chair must start the vote within 7 days of the request. The decision will be based on the majority of the ballots cast.
It is the Chair’s responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favor or discriminate against any group participant or their employer.
The group will conduct all of its technical work on its public mailing list. Any decisions reached at any meeting are tentative and must be confirmed on the mail list.
Amendments to this Charter
The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass.
The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.
June 16, 2015 @ 14.30 [Current Revision] by Mirek Sopek