hxl-team/hxl-vocab

The Humanitarian eXchange Language vocabulary.

hxl-vocab's Issues

add hxl:ftsID to hxl:Org

Co-source or status quo?

We actually define sources individually.
But some data given by the UNHCR is made thanks to the collaboration of up to 3 organizations. In this case a count is reported with 3 lines for keeping the information that it comes from the collaboration of 3 organizations. It means the UNHCR data is split, and the sources names are later concatenated to show the user that some reports are done thanks to this collaboration.

So what is the best way? Manage sources individually or create a co-source?

In the first case, we recognize that it is a collaborative source because the data is in the same container (same validity date) and they have the same count; it is up to the developer to make a relevant query and interpret it well. Let's confirm that, but I believe it is possible to have the same count, the same day, and maybe reported at the same time. So in this case how to make sure it is a collaborative effort or a perfect match of counting by 2 different organization? If it is confirmed it can happen, it is of course a rare case.

In the second case, is it correct to adapt the standard to have a co-source linked to individual sources? Should we create all combinations of source? How?

Actually we have the following scheme:
Population hxl:source Organisation1
Population hxl:source Organisation2
Population hxl:source Organisation3

Proposition to discuss:
Population hxl:source Organisation1_Organisation2_Organisation3
Organisation1_Organisation2_Organisation3 "hasCollaborator" Organisation1
Organisation1_Organisation2_Organisation3 "hasCollaborator" Organisation2
Organisation1_Organisation2_Organisation3 "hasCollaborator" Organisation3

Create new Class `Source`

… and add Person/Organisation (what else?) as a subclass, also add a new subclass Database. This is mostly to be able to pull in the UNHCR data in a clean way.

remove Total Populations from standard and add "no totals" text to defintion of population

Change prefLabel of hxl:Population

… from "Population" to "Population Group"

Change the pref labels of all sub-classes of population to plural form

Internally Displaced Person becomes Internally Displaced Persons, etc. A population can not be single person. Refugees is already plural. Displaced Population is implicitly plural and won't be changed.

Orphaned URIs

How do we handle orphaned URIs? W.r.t. the vocab, this especially refers to properties or classes that we have removed from the standard at some point.

One idea would be to write a clean-up script that goes through all triples in the store on a regular basis and removes all of those which use a property or class that is not in the standard any more.

Some texts in the documentation still refer to camps

Should be changed to APL

HXL namespace on vocab webpage is missing #

https://github.com/hxl-team/HXL-Vocab/blob/master/Tools/static/index.html states namespace as http://hxl.humanitarianresponse.info/ns/ however, the vocabulary at https://github.com/hxl-team/HXL-Vocab/blob/master/Tools/hxl.ttl states http://hxl.humanitarianresponse.info/ns/# as the namespace.

See also: http://hxl.humanitarianresponse.info/ns/index.html

Add definitions for non-defined top-level concepts

Including info that these are just placeholders at the moment.

personCount description

I think the description of personCount is misleading:

• type: int but the description tells it is not resctricted to ints to allow rough estimations. Beyond that, it seems difficult for an app like the dashboard to deal with a non int result.
• no totals: how to report if they don't have detailed counting? Could a personCount without all sex/age/location information be reported anyway without impact on data management?

alternative country pcodes, building URIs automatically and norms

On a location such as http://hxl.humanitarianresponse.info/data/locations/admin/ner/NG, we know from the triple store the country pcode is "NG", and following our URI patterns the country code is "ner".

I'm willing to make the distinction to be able to build the URIs with a script and following the URI pattern. I would say we can remove the "ner/" and we never use it. Why not? For the pattern the pcode is already unique).

About saying the pcode of Niger is "NG" when it should be theoretically "ner" looks inaccurate to me, but it is maybe acceptable not to address a strict normalization issue now.

Alternative country pcodes, building URIs automatically and norms

On a location such as http://hxl.humanitarianresponse.info/data/locations/admin/ner/NG, we have 2 country codes.

The pcode of Niger is "NG" when it should be theoretically "ner", can we have an alternative country code? If the value exist, then we have to use it to build a URI.

And we should explicitly say which one must be used in the URI pattern of a population.

hxl:date, hxl:source, and hxl:method are metadata properties and should be moved to hxl:DataContainer

… once we are done with the first round of demos.

Remove currentLocation

… as discussed today.

Refine defintion of place of origin and nationality

Titles and feature names

Make featureName, featureAltName and featureRefName subproperties of hxl:title.

rdf:seq deprecated on SPARQL 1.1?

I saw this issue that may be interesting to discuss.

A rdf:seq is at the end easy to use but it seems that the lists (rdf:list?) may be more perennial.

http://www.w3.org/2011/rdf-wg/track/issues/24

Definition of DisplacedLocationType needs edit

Create new property to relate hxl:System to a hxl:Organisation

e.g. hxl:operatedBy

Fix Display of LocatedBaseClass

Not shown in the docs, check also the properties where it appears as domain.