Re: Starting the Traffic Event CG

After doing some research looking for existing ontologies I get this
paragraph extracted from Semantic Sensor Network Ontology (
http://www.w3.org/2005/Incubator/ssn/ssnx/ssn):

"This ontology describes sensors and observations, and related concepts. It
does not describe domain concepts, time, locations, etc. these are intended
to be included from other ontologies via OWL imports."

I believe this is a very good practice, to focus on the specific domain you
are studying (traffic) and bypass the side concepts, leaving open the reuse
of other ontologies. For example, in Semantic Sensor Network Ontology, the
only reference to a location is a generic property named "hasLocation".

After, when you are defining the specific information, you can use your
favourite ontology to detail the location (maybe lat / long is enough for
you, maybe you need a specific ontology like dbpedia or geonames or
combinations). Same for life-cycle management (in this case PROV
http://www.w3.org/TR/2013/NOTE-prov-primer-20130430/ seems to be an
interesting option with their Entity-Activity-Agent model), comments, etc.

Therefore, I will consider that in the following iteration of the ontology.
I will design only the specific concepts related to the traffic, leaving
the other "more or less undefined", and always relating to existing
ontologies.


2014-06-05 17:42 GMT+02:00 Daniel Dardailler <danield@w3.org>:

> 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/ [6] or
>> dbpedia http://dbpedia.org/ [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
>> [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 [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 [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 [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/ [3] [1] [1]
>>>
>>>
>>> Date: Current
>>> Status: In operation
>>> Language: English
>>> Dataset: Many (in Europe) http://www.datex2.eu/datex-node [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 [5] [3]
>>> [2] http://www.datex2.eu/datex-node [4] [2]
>>>
>>
>>  Links:
>>  ------
>>  [1] http://www.datex2.eu/ [3]
>>  [2] http://www.datex2.eu/datex-node [4]
>>  [3] http://www.webkb.org/kb/nit/accidentOntology.html [5]
>>  [4] http://www.datex2.eu/content/xml-schema [2]
>>
>>
>>
>> Links:
>> ------
>> [1] https://www.w3.org/community/traffic/wiki/Main_Page#Draft_Plan
>> [2] http://www.datex2.eu/content/xml-schema
>> [3] http://www.datex2.eu/
>> [4] http://www.datex2.eu/datex-node
>> [5] http://www.webkb.org/kb/nit/accidentOntology.html
>> [6] http://www.w3.org/2003/01/geo/
>> [7] http://dbpedia.org/
>> [8] http://www.datex2.eu/sites/www.datex2.eu/files/
>> DATEXIISchema_2_2_0.xsd
>> [9] http://en.wikipedia.org/wiki/Traffic_message_channel
>>
>
>