Process idea: Make a long list of all classes and properties to foster discussion and the decisions

[kimviljanen]

I was thinking on how to get an overview of where we are and what is still to be done - and how to foster systematical approving process to what we are working on. I'm not sure if Protégé has a way to do the following, so here is just a random idea I was thinking on:

Idea: We could (automatically) create a long list of all classes and properties (object, data) e.g. as an CSV file, that could be uploaded to Google spreadsheet.

For example, each class would be on a separate line. And in the next column would be the status of the class: "approved" / "not approved" / "feature suggestion" ...

Such lists could be made for fostering e.g. following discussions:

• class hierarchy -- each subclass relation correct and approved, each line would contain one class relation e.g. Group -- subclassOf Asset ==> approved / not approved
• class name
• class description
• property name
• property hierarchy
• property domain
• property range
• ...

...If Protégé or Github supports such systematical way of going through these things, even better.

Such list approach could perhaps be the way of working when we have the big cleaning first done.

If you think this list approach could be useful, I can probably quite easily write a script that reads the OWL file and creates the lists (e.g. csv files) automatically.

[tormodv]

This can be done by adding a kind of status annotation property and using this. With a sparql query, you can make your table of course.

[tormodv]

Using this branch https://github.com/tormodv/ccdm/tree/StatusProperty

Try this query:

PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
PREFIX ec: <http://www.ebu.ch/metadata/ontologies/ebucore/ebucore#>
SELECT  DISTINCT *
    WHERE { 
    _:a rdf:type owl:Class .
    _:a rdfs:label ?label .
    _:a ec:status ?status . 
} 

[alexander-schulze]

Manually maintaining the documentation in Confluence and keeping it in sync with the model file(s) would come along with respective efforts and up-to-dateness risks. To address that, I (like Tormod) propose to maintain the documentation rather directly within the Ontology and export it to Confluence, or any other documentation target. Maintaining the documentation at the same place together with the model would make it easy to manage and synchronize improvements and extensions.

We already have and use various annotations that document the CCDM entities, and we could easily add some further ones if required - or use "EntityStatus" individuals for annotation instead of numerous literal annotation properties (TBD). Some SPARQLs could easily generate lists of classes and their properties including their constraints and expose relations, directly based on the owl contents. We plan this anyway already for the CDK. Strategically, we could achieve a single source of truth here, with which we can maintain and version control the model and its documentation in a single OWL file and make both machine-readable and reusable from there. Also, we would remain open for potential further internationalization as well as any other kind of documentation target in the future, in any environment, with pretty few effort.

[alexander-schulze]

With the recent reports, I prepared such lists. I could refine them, such that they can be exported to Confluence. However, the question is, if we not just wanted to maintain them in Ontologies and export them e.g. to Excel in case needed. TBD.