colinmaudry / open-contracting-ld Goto Github PK

I originally used owl:ObjectProperty for properties that could have any number of values (arrays in JSON schema) and owl:FunctionalProperty for properties that could only have one value for a given instance of object (a Release can only have one date).

But I'm pretty sure it doesn't work, as I'm pretty sure owl:ObjectProperty implies that the object of the property is an individual (resource), not a literal (string, date, etc.). Nothing to do with cardinality, I believe.

We may stick with OWL properties, but only if:

• it doesn't involve adding much complexity to the OCDS RDF ontology (such as owl:intersectionOf-based solutions)
• the solution is well sourced and argumented (by the way, that applies if the solution doesn't use OWL)

Just a quick issue to flag up some of the discussions from our call last week re: validation.

Our current approach with CSV validation is to convert from CSV to JSON, and validate the JSON, whilst maintaining a source map that lets us give feedback to users on the location of errors in the source file.

I wonder if, with a JSON-LD context, the same would be possible, such that:

• RDF + compaction with a JSON-LD context = OCDS JSON
• We validate the OCDS JSON
• We feedback on errors in ways that make idiomatic sense for the original RDF

This way, any RDF vocabulary does not need to be overly concerned with specific constraints from the JSON schema - just with being able to bi-directionally handle the structure of OCDS.

Hope this makes some sort of sense.

Hello all, we were working around this repository for enhance the actual ontology. By the way we think that is a great start, so we will continuing working on this.

The main idea is to continue the work based on the ontology built by @ColinMaudry to generate a well-structured and semantically correct ontology based on the knowledge of other ontologies of the domain. The intentions is to follow the semantics of OCDS without specifying individual cases as is the case of Paraguay or other countries. Having a generic and compatible ontology.

Once the OCDS ontology (CORE) is finished, our intention is to generate a more specific ontology for our scenario (DNCP https://www.contrataciones.gov.py/ ) relating simultaneously with ontologies in the contracting’s domain, like PPROC. It would be as an extention of the first (CORE) ontology.

Now we explain some tasks that we have made to the initial proposal of Colin.

1. Import Ontology to Protege http://protege.stanford.edu/.

The first step was to import the ontology to Protege software. By doing this, the software restructured ontology and made basic inferences. The structure which was initiated was grouped according to semantic concepts (class by class). Protege structured the ontology according to is Annotation property, DataType or ObjectProperty and then ordered alphabetically taking by reference the name of the property.

2. Identify errors or inconsistencies.

Also some syntactic inconsistencies were found in the ontology since maybe it was done without using any tools for ontological modeling, which results in syntax errors.

For example, the range of the Formervalue class was defined as "xsd: Integer", since there is no such data, protege inferred that it was a new data type. We make the change letter case ( "Integer", "integer") to correct the error.

another typing error found where "comment" was written instead of "comment" and immediately protects inferred as a new data type.

The inference engine added an axiom stating that rdf: descriptions equals owl: AnnotationProperty.

3. Specify the level of data types.

The whole ontology uses the data type rdf: Property. Because ObjectProperty and DataType property are sub classes of Property, we decided to specialize relations with these subclasses.

An important consideration is that the DataType Properties doesn’t need to be defined as functional as most reasoning engines may understand that two literals are different. Example: a reasoner should know That "1" xsd: int is different from "2" xsd: int.

4. modeling considerations. To be implemented

An important consideration is that we use Individuals for open codelists and for closed codelists we use Enumerated Classes. This is because the classes enumerated prevent the declaration of new individuals belonging to this class, thus being more restrictive. Source; https://www.w3.org/TR/2004/REC-owl-guide-20040210/#EnumeratedClasses

In addition, the property was used rdf: Resource, when it has to be rdfs:Resource. In this case we decided that semantically the property is better suited DCTERMS.URI.

Dear Colin,

I couldn't find any UML representation of the OCDS ontology....is there any?

KR

Responding to some of the current questions on the schema here (wasn't sure whether to split this into individual tickets... but thought easiest to start as one and then split out it more discussion).

• is it allowed to provide several amendments to a tender? The property "amendment" in the schema is not very clear.

Agreed that there is a lack of clarity here - and in fact, this, and reflecting on how difficult it would be to round-trip amendment.changes.former_value between serialisations, has led me to write up an OCDS issue on whether we can simplify amendment in version 1.1.

The structure of amendment is such that rather than being a comma separated list of what has changed, changes is an array of objects consisting of changes.property and changes.former_value.

This means you have one amendment, but potentially many structure changes.

As I've flagged in OCDS issue 357 I don't think this is a very good model long term - and to my knowledge, we've not seen fields other than amendment.date and amendment.rationale used in live systems.

• Are tender and procurement synonyms?

Broadly speaking - yes. Checking the docs, I believe there may be a few places where procurement is used to refer to the whole contracting process, but in most instances it is being used to refer to the tender stage of the overall contracting process.

• for the Budget object:
  • source is called "Data Source"
  • description is called "Budget Source"

I'm not sure I understood this question/issue. It looks like you have source = budgetSource and description = budgetDescription

• Why is it an 'amount' for a Transaction and a 'value' for an Award? In the JSON Schema, description of transaction "amount" property: "The value of the transaction" (!). I think the solutio is to reserve 'amount' property for Value objects, and use xxxValue everywhere else.

I thought at first this is because we tried to follow the terms, as well as the semantics of the IATI transaction object - but it looks like this was just an error.

I've opened an issue at open-contracting/standard#359 for this.

• I don't think it's a good idea to store object identifiers as integers, as they are not supposed to be used for calculations, and expose us to issues such as the disappearance of leading zeros.

I believe we have this on the agenda also for 1.1, to remove the ability for a field to be integer or string, and to ensure they are always strings.

:former_value a rdf:Property ;
  rdfs:label "Former value"@en ;
  rdfs:comment "he previous value of the changed property, in whatever type the property is."@en ;
  rdfs:range xsd:string, rdf:Resource, xsd:Integer ;
  rdfs:domain :Change .

That range seems to be empty (intersection of disjoint sets).