You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current implementation of the odml.tools.RDFWriter includes an export of Sections with specific Section.types as RDF classes different than odml:Section. In detail, if a Section.type is found in the type mapping in file odml.resources.section_subclasses.yaml, then the mapped entry is used as new RDF class name instead of odml:Section. As an example, a section with type cell would be exported as odml:Cell.
The idea is to specify Sections of interest which are easier to find in a SPARQL query, if they are proper RDF subclasses of class odml:Section. A query that would look like SELECT * WHERE {?s type odml:Section and ?s odml:hasType 'cell' .} could be simplified to SELECT * WHERE {?s type odml:Cell .} but would still also be found when searching for the more generic SELECT * WHERE {?s type odml:Section .} since odml:Cell is an RDF subclass of odml:Section.
The current implementation does not include an export of everything required to enable this kind of RDF class inference.
The following list of issues map the road to full compliance to RDF class inference in the RDFWriter
On a sidenote, the rdflib implementation also does not provide RDF class inference. To properly test this, libraries like owlrl have to be used in addition to an rdflib graph.
This can cause issues, if a file is uploaded to a graph that similarly does not support class inference. There all queries depending on sub class inference will fail.
From my point of view this is acceptable by default, since the parent of a subclassed Section still connects to its child via the predicate odml:hasSection and in a query that relies on finding all Sections, we can substitute ?s type odml:Section by going one level up and asking for ?parent odml:hasSection ?s.
Users that really do not want this fallback, can deactivate the subclassing feature with the rdf_subclassing flag on the RDFWriter.
Activity
mpsonntag commentedon Jun 3, 2020
On a sidenote, the
rdflibimplementation also does not provide RDF class inference. To properly test this, libraries likeowlrlhave to be used in addition to anrdflibgraph.This can cause issues, if a file is uploaded to a graph that similarly does not support class inference. There all queries depending on sub class inference will fail.
From my point of view this is acceptable by default, since the parent of a subclassed Section still connects to its child via the predicate
odml:hasSectionand in a query that relies on finding all Sections, we can substitute?s type odml:Sectionby going one level up and asking for?parent odml:hasSection ?s.Users that really do not want this fallback, can deactivate the subclassing feature with the
rdf_subclassingflag on the RDFWriter.mpsonntag commentedon Jul 16, 2020
Closed via #400.