- From: Daniel Dardailler <danield@w3.org>
- Date: Wed, 25 Jun 2014 17:34:29 +0200
- To: David Torres <datoga@gmail.com>
- Cc: public-traffic@w3.org
Hello David, nice to see work happening, unfortunately, I'm rather busy
with my "real" work nowadays. Hopefully I'll have more time this summer.
Incidentally, I'm working on the European Commission ICT standard
rolling plan, which has a full section on ITS, with lots of ref to
existing work, so I just wanted to shared this section with our CG.
(it's soon going to be publicly linkable, but not yet, you need an
account/registration, which is free too - so just pasting text, the
Commission said it was ok to share)
(A.) Policy objectives
ITS means applying Information and Communication Technologies (ICT) to
the transport sector. ITS services and applications can create clear
benefits in terms of transport efficiency, sustainability,
accessibility, safety and security, whilst contributing to the EU
Internal Market and competitiveness objectives.
(B.) Legislation and policy documents
(B.1) At European level
C(2013) 885/2013 final: Commission Delegated Regulation (EU) of
15.5.2013 supplementing ITS Directive 2010/40/EU of the European
Parliament and of the Council with regard to the provision of
information services for safe and secure parking places for trucks and
commercial vehicles
Directive 2010/40/EU of the European Parliament and of the Council of 7
July 2010 on the framework for the deployment of Intelligent Transport
Systems in the field of road transport and for interfaces with other
modes of transport
Commission Decision 2008/8455/EC final of 19/12/2008 on the conclusion
of an Implementing Arrangement between the European Commission and the
Department of Transportation of the United States of America in the
field of research on Intelligent Transport Systems and Information and
Communication Technologies applications to road transport
COM(2008)886 final: Communication from the Commission "Action Plan for
the Deployment of Intelligent Transport Systems in Europe
Directive 2004/52/EC of the European Parliament and of the Council of 29
April 2004 on the interoperability of electronic road toll systems in
the Community (OJ L166, 30.4.2004. Corrected version in OJ L200,
7.6.2004)
Commission Decision 2009/750/EC of 6 October 2009 on the definition of
the European Electronic Toll Service and its technical elements
(notified under document C(2009) 7547)
Commission Decision 2008/671/EC of 5 August 2008 on the harmonised use
of radio spectrum in the 5875-5905 MHz frequency band for safety-related
applications of Intelligent Transport Systems (ITS)
Recommendation C/2006/7125: Safe and efficient in-vehicle information
and communication systems: update of the European statement of
principles on human machine interface (EsoP).
(B.2) Others
Extract from ‘ICT Strategy of the German Federal Government: Digital
Germany 2015’ (TFRP011_DE_ict-strategy-digital-germany-2015.pdf).
Measure listed on page 35 ‘Implementation of Directive 2010/40/EU of the
European Parliament and of the Council of 7 July 2010 on the framework
for the deployment of Intelligent Transport Systems in the field of road
transport and for interfaces with other modes of transport’.
Extract from ‘ICT for Everyone – A Digital Agenda for Sweden’
(TFRP037_SV_ICT_for_Everyone-ADigitalAgendaForSweden.pdf). ‘The
Government established a Council for Intelligent Transport Systems (ITS
Council) in June 2010. The aim is to make better use of the
opportunities to use information and communication technology in the
transport system to attain transport and business policy objectives. The
Council is to develop forms of cooperation between authorities and the
business community, provide advice to and speed up the work of the
Swedish Transport Administration and other parties on implementing the
action plan for intelligent transport systems and promote greater
Swedish action in the EU. A final report is due to be presented by 31
December 2012’.
(C.) Standardisation needs, ongoing activities and progress report
(C.1) Commission perspective and progress report
To take full advantage of the benefits that ICT based systems and
applications can bring to the transport sector it is necessary to ensure
interoperability and continuity of the services among the different
systems throughout Europe. The existence of common European standards
and technical specifications is paramount to ensure the interoperability
of ITS services and applications as well as to accelerate their
introduction and impact. International cooperation aiming at global
harmonisation is relevant in this area.
(C.2) Ongoing standards developments
Mandate M/453: Co-operative systems for Intelligent Transport in the
field of information and communication technologies to support
interoperability of co-operative systems for intelligent transport in
the European Community (C-ITS).
The standardisation work for Co-operative Intelligent Transport Systems
(C-ITS) is well advanced in both CEN (TC 278 WG16) and ETSI (TC ITS) but
also other standardisation organisations have provided standards
relevant for C-ITS, falling within the scope of Mandate M/453[1].
Evaluation of the application of existing standards is an ongoing
activity in the standardisation process in the relevant CEN, ISO, SAE,
IEEE and ETSI Technical Committees and their Working Groups.
Release 1 is close to finalization – see ETSI TC ITS technical report TR
101 067 with the Release 1 standards and the development of ISO TR
17465-3 with the CEN/ISO Release 1 list provides the status of the
initial standardisation for cooperative ITS in Europe. After
finalization and publication of the ISO TR 17465-3 a joint document
listing Release 1 standards will be developed also including other
relevant standards from other SDOs such as SAE and IEEE. This will be
done end of 2013/beginning 2014.
http://www.etsi.org/images/files/technologies/Final_Joint_Mandate_M453_Report_2013-07-15.pdf
Cooperation is also ensured through the ITS Standardisation Coordination
Group (ITS-CG).
Contacts with stakeholder organizations have been ongoing as indicated
in the Response to Mandate M/453 and further stakeholder organizations
have been included in the ETSI TC ITS standardisation work such as
ERTICO – ITS Europe, the GSM-A organization and the iMobility Forum. To
provide detailed information about their standardisation activities ETSI
and CEN/TC278 have developed open web sites: www.etsi.org/m453;
www.itsstandards.eu and www.tc278.eu. These websites contain information
about standardisation activities and important events.
The industry organization Car-2-Car Communication Consortium (C2C-CC) is
actively participating in the ETSI TC ITS work providing chairmanship
for working groups and the committee itself. The automotive industry is
also represented and contributes to the standardisation work in CEN in
the relevant working groups. Similarly the COMeSafety2 project strongly
supports the standardisation activities within both CEN/ISO and ETSI.
The iCar Support project provides the chairman of ETSI TC ITS WG2 on
Architecture issues.
The standardisation activities are supported by RTD projects, pilots and
field operational tests in the area of C-ITS, in particular contributing
to fine-tuning the standards, such as DriveC2X, FOTSIS, PRESERVE,
ITSSv6, ComeSafety2, COMPASS4D, iMobilitySupport, SIM-TD, SCORE@F,
eCoMove, EasyWay.
Regarding ICT for Electric Vehicles/Electromobility, there are several
EU funded projects with possible outcomes relevant for standardisation,
such as Mobinet, Mobincity, eCo-FEV; E-DASH, eDAS, SmartV2G, ODIN,
COSIVU, SafeAdapt, Smart-LIC - and the pilots ICT4EVEU, MOBI.Europe,
MOLECULES, SmartCEM and Green Emotion and the support action Smart EV-VC
Internationally, standardisation activities are taken up by ISO TC 204,
with strong cooperation with CEN TC 278, but also by ISO TC 22. ITU has
also established a group on ITS.
In addition standardisation relevant to ITS is done by other
standardisation bodies like SAE, IEEE or ARIB.
ISO/TS 15638-19:2013 ITS – Framework for collaborative telematics
applications for regulated commercial freight vehicles (TARV Part 19).
It is at an early stage of development but not mature enough to serve as
standard for reservation at that stage.
International cooperation for the development of harmonised global
standards is particularly important in these areas. Agreements with the
US Department of Transport and with the Japanese Ministry for Land
Transport and Industry have been concluded regarding ICT applications to
road transport. Cross-regional harmonisation task groups (HTGs) have
been established in this area. Currently the CAMP/WIIC and the C2C-CC
and Japanese OEM are working to solve coordination requirements for Day
1 deployment expected in 2015 in Europe.
ETSI has cooperation and liaison agreements with relevant standards
organizations such as IEEE, SAE, ISO, IETF, and standardisation
supporting industry groups like TISA. Additionally ETSI have liaisons
and contacts with regional and national standards organizations such as
ARIB (Japan), CCSA (China) and TTA (Korea) as well as the Asian Pacific
Telecommunication organization (APT).
IEEE has standards activities in many aspects of ITS, such as vehicle
communications and networking (IEEE 802 series), vehicle to grid
interconnectivity (IEEE P2030.1), addressing applications for
electric-sourced vehicles and related support infrastructure and also
communication for charging (IEEE 1901). In addition, the IEEE 1609
Family of Standards for Wireless Access in Vehicular Environments (WAVE)
define an architecture and a complementary, standardised set of services
and interfaces that collectively enable secure vehicle-to-vehicle (V2V)
and vehicle-to-infrastructure (V2I) wireless communications. These
standards are designed to provide the foundation for a broad range of
applications in the transportation environment, including vehicle
safety, automated tolling, enhanced navigation, traffic management and
many others. For more information please see
http://standards.ieee.org/develop/msp/its.pdf.
(C.3) Member States and other Stakeholder remarks
Pursuant Directive 2010/40/EU, Member States have submitted to the
Commission information on their national activities and projects on
national ITS actions. In addition, several Member States gave their
agreement to the publication of their initial contributions:
http://ec.europa.eu/transport/themes/its/road/action_plan/its_national_reports_en.htm
(D.) Proposed new standardisation actions
(D.1) Standards developments
Co-operative systems. There is a need to complete the minimum set of
standards required to deploy C-ITS systems and application, completing
the activities foreseen in the M/453, and achieving the Release 1 and 2
for C-ITS, including inter-vehicle communications (V2V), vehicle to
infrastructure and infrastructure to vehicle communications (V2I/I2V)
and infrastructure to infrastructure communications (I2I). Plugtest
activities for interoperability testing, and guidelines with methods for
assessing the conformity of the identified minimum set of standards are
also needed.
Electric Vehicles (EV): Taking into account the C-ITS architecture, ICT
related standards to support electric vehicles take-up, in particular
vehicle-to-grid (V2G) communication protocols, message datasets,
interfaces, and back-office platforms. Regarding in-vehicle systems,
integration of EVs communication with car architectures; subsystem
partitioning and their interfaces; X-by-wire controls; Testing and
management of energy storage systems with on board BMS, metering and
certification.
Digital Maps: There is a need for standards / specifications to steer
and manage the integration of accurate (public) road data in digital
maps, and their timely updating. Work should be based on the results of
the ROSATTE project (7FP) and subsequent activities carried out by the
iMobility Forum 'Digital Maps Working Group', and consider a possible
alignment with the INSPIRE technical Framework.
(D.2) Other activities around standardisation
In the context of Urban ITS and in the perspective of smart cities,
there is a need to ensure that the existing standards are properly
adapted for urban environment, notably to ensure a better impact on
market solutions, via public procurement, building on insights and best
practices from Civitas, POSSE and smart cities projects. The objective
is to better connect existing networks, foster strong cooperation and
creation of interoperable urban-inter-urban interfaces and foster more
extensive use of all transport modes. For this, data formats need to be
defined (including for new mobility services), as well as exchange
protocols which need to be interoperable - mode to mode and intermodal
and specify them. It will be considered whether a specific Mandate in
this area is needed. This mandate would enable the development of new
standards, where appropriate (e.g. in the domain of traffic management,
or city logistics) and harmonisation of existing standards (e.g. in the
domain of multimodal information and smart ticketing), such as::
Transmodel, the European Reference Data Model for Public Transport,
CEN-TC278 ENV12896;
IFOPT, (CEN/TS 00278207) a CEN Technical Standard defining a data model
for the Identification of Fixed Objects in Public Transport (e.g. stop
points, stop areas, stations, connection links, entrances, etc.);
SIRI, (CEN/TS 00278181-1 to 5), a European CEN technical standard
defining Service Interface for Real-Time Information relating to public
transport operations;
NeTEx, a prCEN/ Technical Standard currently in development. It is based
on Transmodel, extended with additional concepts from IFOPT and SIRI.
NeTEX is divided into three parts: Part 1 - Transport Network and Part 2
- Schedules Part 3 - Fares and data for AVL
Standards supporting the emerging interoperable fare management (IFM)
systems: Public Transport interoperability (IOPTA) standard ISO EN 15320
defining the functional system architecture and the application
scenarios; the EN 1545 standard describing the data elements and the ISO
EN 24014-1 standard, defining functional system architecture and the
application scenarios.
Urban stakeholders should also actively participate.
Open in-vehicle platform architecture: the development, operation and
user acceptance of vehicle-based intelligent transport systems and
services will benefit from an agreed open in-vehicle platform
architecture enabling a 'single platform – multiple services' approach
and ensuring interoperability/interconnection with legacy in-vehicle
communication networks (CAN-bus) and (generic) infrastructure systems
and facilities. The issue so far has been addressed in fragmented way,
providing building blocks (e.g., the research projects CVIS, GST,
OVERSEE, the eSafety Working Group on SOA and the recommendations of the
EeIP Task Force OPEN and the study from the ITS) but an overall logical
and cost-effective synthesis seems to be lacking. Prior to launching the
Mandate it is necessary to define the precise standardisation
requirements needed, taking into consideration latest results from a
study launched under the ITS Action plan (action 4.1) focusing on
synergies among legal provisions and obligations for HGV.
The development and use of novel ITS services and applications imply
guidance and potentially technical specifications to ensure a correct
and safe on-board 'Human-Machine-Interaction', enabling safe integration
and operation of nomadic devices. Results of the research project AIDE
("Adaptive Integrated Driver vehicle InterfacE"), the conclusions of the
Nomadic Device Forum and the European Statement of Principles (ESoP) on
safe HMI shall be taken into consideration.
International cooperation aiming at achieving the necessary global
harmonisation of standards is paramount in the field of ITS, in
particular with the USA and Japan, with which implementation agreements
exist, but may also be extended to other regions.
[1] The final status report under mandate M/453 is available at:
http://www.etsi.org/images/files/technologies/Final_Joint_Mandate_M453_Report_2013-07-15.pdf
On 2014-06-20 16:13, David Torres wrote:
> Hi,
>
> After some iterations, I decided not to use PROV ontology because it
> didn't fit too well to the traffic model. Instead, after some research
> I found some examples with LODE: linked events
> ontology http://linkedevents.org/ontology/ [9]. Although this
> ontology it's designed to be very simple, it brings a lot of links
> between well-known ontologies, like DUL, Dublin Core, GEO, etc.,
> therefore is very easy to reuse the most typical concepts like dates,
> locations, etc.
>
> This version of the ontology follows the guidelines set in my previous
> emails, including a little traffic event classification, vehicle and
> person modelling, etc. Please find attached the last version of the
> ontology, some RDF examples (one abnormalTraffic and one Accident1)
> build programmatically using the Jena Framework in Java.
>
> Also, I have been testing the features of the ontology using SPARQL
> queries. As example, this query gives as result a list of towns
> (results mashed up with dbpedia.org [10]) with more than 2000
> inhabitants which are near to the coordinates of the points of the
> itinerary of the traffic event.
>
> PREFIX geo: <http://www.w3.org/2003/01/geo/wgs84_pos# [11]>
> PREFIX tff: <http://www.w3.org/community/traffic/ [12]>
> PREFIX list: <http://www.co-ode.org/ontologies/list.owl# [13]>
> PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns# [14]>
> PREFIX dul: <http://www.loa-cnr.it/ontologies/DUL.owl# [15]>
> PREFIX dbo: <http://dbpedia.org/ontology/ [16]>
> PREFIX dbp: <http://dbpedia.org/property/ [17]>
> PREFIX dbr: <http://dbpedia.org/resource/ [18]>
> PREFIX foaf: <http://xmlns.com/foaf/0.1/ [19]>
> PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema# [20]>
>
> SELECT ?id ?itinerary ?point ?townName ?population FROM
> <abnormalTraffic.rdf>
> WHERE
> {
> ?point geo:latitude ?latitude .
> ?point geo:longitude ?longitude .
> ?itinerary tff:hasPoints ?point_init .
> ?listItem rdf:type tff:SpatialThingList .
> ?listItem list:hasContents ?point .
> ?id dul:hasLocation ?itinerary
>
> SERVICE <http://dbpedia.org/sparql [21]> {
> ?s dbp:settlementType dbr:Municipalities_of_Spain .
> ?s geo:lat ?dbolat .
> ?s geo:long ?dbolong .
> ?s rdfs:label ?townName .
> OPTIONAL {?s dbo:populationTotal ?population}
>
> FILTER (?dbolong > ?longitude - 0.1 && ?dbolong < ?longitude + 0.1 &&
> ?dbolat > ?latitude - 0.1 && ?dbolat < ?latitude + 0.1)
> FILTER (?population > 2000)
> FILTER (lang(?townName) = 'es')
> }
> }
>
> It has been tested using Jena 2.11.1 (with the command-line ARQ).
>
> I believe there are a lot of possibilities opened now. From my point
> of view, I think the best option would be review and finish the
> version of this basic traffic ontology and, after that, begin to
> documentate it in the website.
>
> Regards,
> David
>
> 2014-06-10 12:00 GMT+02:00 David Torres <datoga@gmail.com>:
>
>> - Person: it is defined in PROV model like "Agent", who does an
>> "Activity" that affects to an "Entity". Maybe this concept should be
>> specialized to "Driver", "Passenger", "Pedestrian"..... What is
>> SSID? Security insurance ID?
>>
>> - Vehicle: DATEX II has a widely studied classification of vehicles
>> and their features (by the way, I'm still waiting to response about
>> the enquiry about IPR of DATEX II).
>>
>> - Weather condition. In this case I would separate this two
>> situations:
>> * General weather conditions (and non weather, low sun glare,
>> fire are definitely non-weather problems). This should be defined in
>> a external "weather" ontology. Unfortunately I've been unable to
>> find a standard ontology, only local extended
>>
> efforts: http://www.semantic-web-journal.net/sites/default/files/swj281_0.pdf
>> [1].
>> * Road state conditions (example, icy patches): this is
>> directly related to a road so it should be defined.
>>
>> - Organization: PROV model kind of "Agent".
>> - Anything: PROV model kind of "Agent" and "Entity".
>> - Health stuff: it could be linked to geospecies taxonomy and maybe
>> health ontologies to include this information, although after a
>> little review, the best could be to include some enumerations and
>> use it directly.
>>
>> Regarding the Road Accidents I believe these definitions and other
>> (type and preliminary causes of the accident) should be also
>> included when the concept would be developed.
>>
>> 2014-06-05 18:18 GMT+02:00 Daniel Dardailler <danield@w3.org>:
>>
>> So, following up on what I said, I think our ontology should also
>> consider that in addition to Event, a generic description of
>> - Person (e.g. with an age, SSID, address, desc, etc)
>> - Vehicle (with insurance, ID, brand, color, type, type of
>> licence to drive them, potential damages, etc)
>> - WeatherCondition (rain, snow, ice, night, light, etc)
>> - Organization (e.g Insurance, driver licence's bureau, etc)
>> - Anything (e.g. Train, Electric Line, Rock)
>> - HealthStuff (e.g. animal, human, medical condition, types of
>> injuries, drug conditions, etc)
>>
>> exist somewhere, is not specific to traffic, and is not really our
>> job, or is secondary (we need to check if they exist and to what
>> extend they have what we need)
>>
>> In the case of RoadAccident, as a subclass of TrafficEvent, we
>> should focus on
>> - definition of driver, role, passenger, pedestrian
>> - defitinition of roadtype, roadconditions, lane#, violations
>> - relation between vehicles, passenger, driver, pedestrian,
>> moving, parker, etc
>> - description of cause, context, speed, drugcondition, presence
>> of protection, etc
>>
>> On 2014-06-05 17:42, Daniel Dardailler wrote:
>> I'm not an expert either, I think at some point we may want to ask
>> an
>> owl expert through other W3C list (e.g. for the need of constructs
>> like Comment, ID, hasVersion, or hasSomething in general as a way
>> of
>> organising semantics).
>>
>> At a higher level of design, looking at your base ontology, and in
>> a
>> good spirit of reuse (the opposite of the NIH spirit, "not invented
>> here", which I had to fight all my life as a standardizer ;), I
>> wonder
>> if basic location stuff like
>> - point (where you reuse lat/long from geo:)
>> - area, segment
>> - neartown, roadkm, locationname, etc
>>
>> shouldn't be taken from the base geo stuff, where it's got to be
>> IMO.
>> Or asked if they have plan to have it there. Or if it's OK that we
>> do
>> it in Traffic.
>>
>> TrafficLocation could be a subclass of this base (but powerful)
>> location and add primary, secondary, etc. maybe roadnumber if
>> that's
>> not generic enough for the geo ontology.
>>
>> Same thing for Event, I'd add a Date BTW, but I'd bet there is a
>> generic definition somewhere with:
>> - date
>> - location (as a compound object with point, road, nearby, etc)
>> - desc (string)
>>
>> and a TrafficEvent could add in its subclass things like
>> datepublished, dateRange to store things like roadwork for 12h, or
>> have startEvent and endEvent as subclasses.
>>
>> So in short, how about assuming that the really generic classes
>> like
>> Location (with rich semantics already, e.g. used in gmap)
>> Date (as used in email)
>> Event (simple enough we can define it: Date, Location, Desc)
>>
>> will come from some external ontology, not traffic ?
>>
>> On 2014-06-04 17:27, David Torres wrote:
>> Hi,
>>
>> After some experiments, I have developed a tiny ontology about
>> traffic
>> events (please find attached the OWL/XML result and a small graph
>> about the ontology). I have used Protégé 4.3 (last stable
>> version)
>> to design the hierarchy and include some properties, some of them
>> pointing to other ontologies (e.g. basic geo
>> ontology, http://www.w3.org/2003/01/geo/ [2] [6] or
>> dbpedia http://dbpedia.org/ [3] [7]). I believe this may bring
>> powerful
>> features based on the Open Linked Data characteristics.
>>
>> I'm not an expert in OWL and RDF technical details (probably the
>> ontology has something wrong), so it would be great if a real
>> expert
>> would take this OWL and make some comments about it!
>>
>> Regards,
>> David
>>
>> 2014-06-03 16:40 GMT+02:00 David Torres <datoga@gmail.com>:
>>
>> Hi, see below
>>
>> 2014-06-02 23:16 GMT+02:00 Daniel Dardailler <danield@w3.org>:
>>
>> Hello David, all
>>
>> see below
>>
>> On 2014-06-02 11:15, David Torres wrote:
>> Hello Daniel,
>>
>> I will try to give a short description about the organisation of
>> all
>> matters related to DATEX II. Easyway was a european research
>> project
>> (I said "was" because it ended some months ago and now they are
>> reorganising their groups) promoted by the EC. Their main task was
>> to
>> develop specs (including methodology, models, documents, xsd,
>> applications, examples, etc.) and provide these specs to the WG8,
>> dependent group of CEN (TC278, ITS standardisation) to be
>> normalised
>> as Technical Specification.
>>
>> The current roadmap of normalisation is:
>>
>> - Part 1: Modelling methodology: normalised (2011).
>> - Part 2: Location referencing: normalised (2011)
>> - Part 3: Traffic information: normalised (2011).
>> - Part 4: Variable Message Settings: normalised (2013)
>> - Part 5: Measured and Elaborated Data: normalised (2014).
>> - Part 6: Parking information: ongoing (probably 2015).
>>
>> Regarding your concerns about the IRP, of course it must be
>> considered. As far as I know, the only process you have to fulfill
>> in
>> order to work with DATEX II is to download and use it. Anyway, I
>> still
>> believe a formal request for permission is always a good practice.
>>
>> There are (at least) two different things to consider. First there
>> is the permission to point at and download the DATEX spec (for
>> free,
>> usually not the case for CEN/ISO, etc, but seems fine here), so to
>> use it, e.g. as a reference or to implement something based on it,
>> without having to pay some royalty to the IPR owners of the
>> semantics behind the names in the spec (to be checked, but being
>> funded through EC funding, it's got to be RF).
>>
>> Then there is the right to do derivative work, that is, to take
>> pieces and bits, e.g. an enum here, a type construct there, and to
>> define something new, which doesn't need the original work anymore.
>> Usually it's not ok to do that for de-jure spec like from ISO, or
>> an
>> ESO like CEN. In a CG, we do pre-standardization, so it's usually
>> OK
>> to experiment, but if we expect a potential take up in a "real" W3C
>> working group later on, we better check this one.
>>
>> Ok, I have some contacts in CEN and working groups so definitely I
>> will contact them in order to avoid future issues.
>>
>>
>>
>> With "good starting point" I meant it could be taken as
>> reference. The
>>
>> Is it even possible to link to a DATEX type or enum if we plan to
>> reformalize their tree schema model in terms of graph/ontologies ?
>> We're bound to cut&paste the strings no ? Could we just point at
>> the
>> definitions then ?
>
> Technically, I'm not sure it's possible to make links directly. The
> main model is exported to a XSD (last version:
> http://www.datex2.eu/sites/www.datex2.eu/files/DATEXIISchema_2_2_0.xsd
> [22]
> [8]), but this XSD has not URIs or other semantic information so
> maybe
> it'd need some work to be more "usable".
>
>
>
>>> scope... I think it has to be defined. As long as the group is
>>> named
>>> "traffic ontology", I suppose the best option should be to define
>>> the
>>> domain of traffic widely and not to constraint to a one only
>>> subfield.
>>> My proposal would be to use a top-down approach, with these
>>> phases:
>>>
>>> - Define a general traffic domain, including a minimal set of
>>> information about a traffic incident: ID, Date, General type,
>>> location, urgency and level of service. This information is more
>>> or
>>> less the same information that RDS-TMC (ISO 14189) supports (one
>>> of
>>> the main objectives of RDS-TMC was precisely to deliver the
>>> necessary
>>> information to users to be aware of a traffic situation in their
>>> route).
>>
>> Is this specification freely available ?
>
> No, it's not. Unlike DATEX II the specification is not open, but, due
> to is a very extended technology, its functional details are well
> known. http://en.wikipedia.org/wiki/Traffic_message_channel [23] [9]
>
>
>
>> I'd really like to see an example of definition of a generic traffic
>> event using on ontology language of some kind, e.g. OWL, and
>> referencing this ISO work, to understand what
>> dependencies/extensions are present.
>
> I can prepare something in the following days...
>
>>> - Describe a list of traffic subdomains (Accident, Roadworks,
>>> Management, etc.) and a set of reusable domains (Vehicle
>>> classifications, data quality description, etc.), which could be
>>> used
>>> for the rest.
>>
>> Sounds good. We can use a wiki to share our ideas. I just created a
>> page for our CG:
>> https://www.w3.org/community/traffic/wiki/Main_Page#Draft_Plan [4]
>> [1]
>> Feel free to add there, remove, or create new pages, etc.
>> You should have the rights for editing.
>
> Perfect, I've just added some tasks and possible deliverables.
>
>
>
>>> - In several subgroups, work in each subdomain separately,
>>> relating it
>>> to the main traffic domain.
>>
>> I suppose we'll have to prioritize the subgroup deliverables, as
>> it's likely we'll have to work in series rather than in parallel
>> (unless lots of volunteers show up suddenly)
>
> Indeed!
>
>
>
>>> This top-down approach would have the advantage that you get a
>>> final
>>> version very early. This allows to start to build frameworks,
>>> application tools, etc. For example, it could be possible to set
>>> a
>>> complete broadcasting system, from data sources to users.
>>
>> Does broadcasting (e.g. using the FM band) bring requirements on
>> performance ? size, etc ?
>
> I see broadcasting applications using Internet and avoiding to use
> FM,
> DAB or other more restricted technologies. Nowadays, a vast majority
> of people are connected when they are driving (connected cars are
> coming but, meanwhile, to have a smartphone with Internet access
> inside a car is not a big deal).
>
> In this case, always following some limitations (e.g. please don't
> send real-time CCTV stream using this kind of channel!), the
> performance or size is not a problem. I think currently it's possible
> to process and inference RDF in a tiny client in an app installed in
> your Android / IPhone.
>
>>> About deliverables, examining the websites of other well-know
>>> ontologies, there are always: textual documentation, modelling
>>> graphs
>>> (UML, graph build with Protégé, etc.), resources (including the
>>> ontology, using OWL), use cases and examples). I'm comfortable
>>> with
>>> UML in general, but tools like Protégé have been designed to
>>> develop
>>> ontologies and they have some interesting tools integrated
>>> (graphical
>>> builder, reasoner, OWL profile calculator, etc.).
>>
>> I'll use whatever tool I can install on Windows.
>> Best would be a webapp tools though (e.g. webprotegé)
>
> We'll give it a try.
>
>
>
>>> Finally, I have no problem being volunteer performing, for
>>> example,
>>> some steering or technical tasks. Always with the limitation of
>>> the
>>> time, a few hours per week is ok for me, as you pointed.
>>
>> Thanks for that.
>>
>> I think we should start with a teleconf, or just a call with a
>> couple of other potential lead/chairs for the group.
>>
>> Last time I attempted to organize a call, I failed finding a proper
>> teleconferencing tool usable by all participants.
>> (we have one at W3C, but not available to CG/the general public)
>>
>> But we can start by designing datatypes through the wiki too, it's
>> more fun ;)
>
> Yes, the time change is always a problem to arrange this kind of
> meeting, maybe the best option is to start to work and wait to get
> feedback from the other people of the group.
>
> David
>
>
>
>> I hope I have answered all your questions.
>>
>> Regards,
>> David
>>
>> 2014-05-31 13:46 GMT+02:00 Daniel Dardailler <danield@w3.org>:
>>
>> Hello David
>>
>> Thanks for the new pointers, it's important to be knowledgeable of
>> this work which seems well advanced and implemented. I need to
>> better understand what are CEN's and the EC roles in these
>> standards, as there may be political aspects to be considered. IPR
>> is one potential source of concerns when someone starts a new
>> standard from some existing standard.
>>
>> A few comments.
>>
>> First, on the logistics side, as I explained before, what this CG
>> (Community Group) needs is a couple of volunteers willing to act as
>> co-chair, editors, organizing teleconf, tracking progress,
>> reporting, etc. That is, ready to spend a few hours per week on it
>> at a minimum.
>>
>> If some folks are willing to try, I'm willing to spend some time
>> explaining how this group mgnt is done at W3C, e.g. live on the
>> phone.
>>
>> On the technical side, I need to look more closely at the DATEX II
>> XML schema
>> http://www.datex2.eu/content/xml-schema [5] [2] [4]
>>
>> but I already see it includes a full descriptor for Accident, with
>> Vehicle, person, roadtype, etc. And that it's only a tiny portion
>> of
>> the whole semantics provided by DATEX.
>>
>> What do you have in mind when you say "good starting point" ? Only
>> the Accident part ?
>>
>> What would be your ideal deliverable(s) for this CG BTW ? Both in
>> terms of scope (just accident, or traffic in general) and choice of
>> design formalism (tree, graph, oo, xml, etc).
>>
>> I've been pushing for describing Web ontologies in RDF/OWL or some
>> equivalent high level graph oriented framework from the start, but
>> some people were happy with XML as a starting point for instance.
>> There is no obligation from the W3C point of view to choose one or
>> the other. My concerns with starting with XML is that in practice,
>> XML users tend to recreate their own adhoc framework to simulate
>> multiple inheritance, or other logical or graph-like features
>> already present (and standardized) in a richer language (such as
>> OWL). My only constraint is that I don't want to have to learn this
>> sort of XML-improved layer. On the other hand, I'll happily invest
>> time in learning a graphical-oriented ontology editor kind of tool.
>>
>> In any case, scoping should be our first task. My preference goes
>> to a limited scoping: road accident in their context (geo/date,
>> vehicle, driver condition, road type, etc). And try to think graph
>> out of the box.
>>
>> On 2014-05-29 17:03, David Torres wrote:
>>
>> Hello everyone,
>>
>> My name is David Torres, I work as Technical Consultant at
>> University
>> of Valencia (Spain). There is an emerging interest in Spain on
>> Linked
>> Open Data matters and I was looking for a standard ontology based
>> on
>> Traffic Information. The only group I've found is this one and
>> I've
>> just joined, but it seems is quite "idle"...
>>
>> I'm a kind of expert in DATEX II, a traffic model promoted in
>> Europe
>> to be the standard to use to exchange all kind of information
>> related
>> to traffic data. I think it could be a good starting point. The
>> PSM
>> (Platform Specific Model) is based in XML.
>>
>> Description: DATEX II (ISO 16157)
>> Relevance: all kind of incident, accident, traffic data, parking
>> information, CCTV, VMS, etc. It supports the use of extensions.
>> Link: http://www.datex2.eu/ [6] [3] [1] [1]
>>
>> Date: Current
>> Status: In operation
>> Language: English
>> Dataset: Many (in Europe) http://www.datex2.eu/datex-node [7] [4]
>> [2]
>> [2]
>>
>> PS: As long as I can see this mail list is frozen I'd like to get
>> feedback about your interest by working on this new traffic
>> ontology.
>>
>> Kind regards,
>>
>> David
>>
>> Links:
>> ------
>> [1] http://www.webkb.org/kb/nit/accidentOntology.html [8] [5] [3]
>> [2] http://www.datex2.eu/datex-node [7] [4] [2]
>
> Links:
> ------
> [1] http://www.datex2.eu/ [6] [3]
> [2] http://www.datex2.eu/datex-node [7] [4]
> [3] http://www.webkb.org/kb/nit/accidentOntology.html [8] [5]
> [4] http://www.datex2.eu/content/xml-schema [5] [2]
>
> Links:
> ------
> [1] https://www.w3.org/community/traffic/wiki/Main_Page#Draft_Plan
> [4]
> [2] http://www.datex2.eu/content/xml-schema [5]
> [3] http://www.datex2.eu/ [6]
> [4] http://www.datex2.eu/datex-node [7]
> [5] http://www.webkb.org/kb/nit/accidentOntology.html [8]
> [6] http://www.w3.org/2003/01/geo/ [2]
> [7] http://dbpedia.org/ [3]
> [8]
> http://www.datex2.eu/sites/www.datex2.eu/files/DATEXIISchema_2_2_0.xsd
> [22]
> [9] http://en.wikipedia.org/wiki/Traffic_message_channel [23]
>
>
>
> Links:
> ------
> [1]
> http://www.semantic-web-journal.net/sites/default/files/swj281_0.pdf
> [2] http://www.w3.org/2003/01/geo/
> [3] http://dbpedia.org/
> [4] https://www.w3.org/community/traffic/wiki/Main_Page#Draft_Plan
> [5] http://www.datex2.eu/content/xml-schema
> [6] http://www.datex2.eu/
> [7] http://www.datex2.eu/datex-node
> [8] http://www.webkb.org/kb/nit/accidentOntology.html
> [9] http://linkedevents.org/ontology/
> [10] http://dbpedia.org
> [11] http://www.w3.org/2003/01/geo/wgs84_pos#
> [12] http://www.w3.org/community/traffic/
> [13] http://www.co-ode.org/ontologies/list.owl#
> [14] http://www.w3.org/1999/02/22-rdf-syntax-ns#
> [15] http://www.loa-cnr.it/ontologies/DUL.owl#
> [16] http://dbpedia.org/ontology/
> [17] http://dbpedia.org/property/
> [18] http://dbpedia.org/resource/
> [19] http://xmlns.com/foaf/0.1/
> [20] http://www.w3.org/2000/01/rdf-schema#
> [21] http://dbpedia.org/sparql
> [22]
> http://www.datex2.eu/sites/www.datex2.eu/files/DATEXIISchema_2_2_0.xsd
> [23] http://en.wikipedia.org/wiki/Traffic_message_channel
Received on Wednesday, 25 June 2014 15:34:59 UTC