URI policy

[FranckCo]

COOS currently defines all its artifacts in the http://id.unece.org/def/coos space.
Other possibilities can be considered. For example, Insee uses a different namespace for RDF constructs (ontology components, graphs) and for individuals.

In all cases, it must be guaranteed that the namespaces used are durably reserved for RDF resources.

A document describing the URI policy has to be produced as a deliverable of the COOS activity.

[FranckCo]

A first version of URI policy is available at https://github.com/linked-statistics/COOS/blob/master/uri-policy.md for discussion.

[ChLaaboudi]

Dear Franck,

GSBPM is organised in phases (Level 1), split in sub-processes (Level 2)
Example:
Analyse > 6.3 Interpret and explain output (http://id.unece.org/activity/subProcess/6.3)

GAMSO is organised in _Activity area_s split in activities
Example:
Corporate Support > 3.7 Manage Finance (http://id.unece.org/activity/activity/3.7)

How are you representing the URI for the upper levels:

• GSBPM Phases;
• GAMSO Activity Areas ?

If we apply the domain http://id.unece.org/activity/ to GAMSO and GSBPM resources, it won't obvious to know what resource comes from GAMSO or GSPM. A solution might be to define an generic URI for GAMSO or GSBPM as a conceptScheme and assign the instance resources to their respective scheme.

Best regards,

Christine

[abrycsaba]

We read this suggested URI policy and we agree with this version from the point of view of both content and detail.

[FlavioRizzolo]

I'm not an expert on URI's, so please take this with a grain of salt: I don't like the idea of encoding part of the ontology structure in the domain, as implied here:

domain denotes the business domain relevant for the resource, for example: activities, products, organizations, etc.

Type should probably be good enough to link it to the ontology. Domain then could be used to encode something beyond of what is already modeled in the ontology, e.g. additional information about it, context, etc.

Perhaps something like this: http://id.unece.org/coos/subProcess/6.3

[FlavioRizzolo]

For the domains, it seems our classes can be classified in the three high-level Prov classes: activity, entity and agent. We may want to start with those three domains, see whether they work and if we need further classification.

[FranckCo]

Yes, that's also a possibility. For now we only have activities, so let's go with that. Rather 'activities', to avoid repetition with type Activity and make it clearer that it is a naming context. I change the policy and Turtle file and close the issue.