Allow ontologies with blank nodes

[alejgh]

We need to support the synchronisation of changes regarding blank/anonymous nodes. For example:

:played_by a owl:ObjectProperty ;
     rdfs:label "played by"@en ;
     rdfs:domain [ a owl:Restriction ;
             owl:onProperty :played_by ;
             owl:someValuesFrom :Song ] ;
     rdfs:range [ a owl:Restriction ;
             owl:onProperty :played_by ;
             owl:someValuesFrom :Artist ] .

In order to implement this we will need to add a way to parse BNodes from RDFLib in our TripleInfo.from_rdflib method.

I don't know if this will be straightforward or not.

I think that maybe the predicates inside these blank nodes should be treated as qualifiers in wikibase, but we need to discuss this (e.g. what predicate could be used to define the value and not the qualifiers...).

We should also consider if this issue includes the functionality of parsing 'QualifiedValues' from the hercules-ontology.

[alejgh]

This is a really interesting issue.

There was already a task on the Wikimedia Phabricator platform regarding this. In Wikidata blank nodes represent either:

• Properties with unknown values.
• OWL constraints for datatypes.

I am thinking currently about three different ways to handle blank nodes:

• Treat them as unknown values. We may lose information if we do this.
• Create a new entity with the code generated by rdflib as label. We will store all the information with this, but there is a possibility that a label could be repeated in the long run and readability would be hindered overall.
• Try to add each statement on the blank node as qualifiers and references of the original statements. Some things need to be answered here first:
  • What is the predicate that will define the value of the statement?
  • What will happen when the predicate defined above does not exist for the blank node?
  • Which predicates are used as qualifiers and which ones as references? We will lose flexibility if we hardcode things.

Other possibilities are appreciated and welcome.

Each one has various degrees of complexity, but in my opinion we should choose the cleanest and most reasonable solution to solve this if possible.

This is an important decision to be made, and it needs to be as stable and coherent as possible. I will discuss it with @labra and @spitxa.