Ordering and Grouping of Data Items

[cuboideum]

Implementation of skeletal inventories in AnthroGraph has brought up the problem how the layout of data items on data entry forms can be specified. The same problem occurs with tabular output from queries. As it does not pertain to the specific implementation in AnthroGraph but rather to the implementation of RDFBones in general these specifications should be part of the core ontology.

The following two specifications should be implemented:

• Grouping: Data items that have a higher affinity to each other than to the other data items in the dataset form groups (e.g. the scorings for the left and the right side of the frontal bone or for the epiphyses and section of the diaphysis of one femur bone). On paper forms, data items of the same group are often positions in a horizontal row.
• Ordering: Data items should appear in a meaningful order on entry forms or in tabular output from queries. On paper forms, ordering commonly defines how items are positioned in the direction of writing, i.e. from left to right and from top to bottom of the page. In database forms, this order is often referred to as 'activation sequence' as it defines how users can change between data fields using the tab key.

Here, several options for implementing these functionalities into RDFBones are outlined and discussed.

Data properties with measurement data instances

The intuitive solution that @zarquon42b and myself have come up with is to add numeric data properties to data items that describe a sequence. As datasets are made up of measurement data, the properties should be part of these elements. The following example shows two measurement data forming a group (scores of the frontal bone) and the positions 1 and 2 in the activation sequence of a skeletal inventory section. Grouping and ordering are defined by the data properties 'grouping number' and 'activation sequence number'.

Advantages of this approach

• Simple solution that is easy to implement.

Disadvantages

• The data properties cannot be defined by class restrictions as the the same measurement datum ('Representation in four states' in the example) is used to score several regions of interest. Therefore, definition of ordering and sequence on the ontology level is only possible by employing very complex statements.
• Use of measurement data classes in other ontology extensions is compromised. If they appear in a different activation sequence there, data properties have to be changed. While this is not strictly impossible it still creates confusion for ontology authors.
• If classes are shared by several ontology extensions, they might appear with different ordering and grouping specifications. This would render queries across the entire graph unsatisfactory.

Data property restrictions on ROI classes

At least in skeletal inventories, each score is about a specifically defined anatomical region of interest (ROI). As a consequence, data property restrictions on these classes are easier to realise than with classes for measurement data.

Advantages

• Simple solution that is easy to implement.
• Specifications are bound to classes on ontology level.

Disadvantages

• The parts of a dataset are the measurement data, not the ROIs. For authors of ontology extensions it is difficult to understand why ordering and grouping should be defined with the ROIs and not with the measurement data.
• Use of ROI classes in other ontology extensions is compromised (cf. above).

Specific classes for specifications

Specification of ordering and grouping should be stated with the skeletal inventory section class instead of other elements that might be reused with other dataset types. But direct restrictions on the skeletal inventory section class would have to be very complicated and difficult to query. A solution might be to introduce specific classes for specifications pertaining to data elements in a data set. These would be about the data set (i.e. the skeletal inventory section) on the one hand and the data element (i.e. the measurement datum) on the other. Grouping and ordering would be specified through data property restrictions on the specification classes. An example for a definition of such a class would be the following:

    <owl:Class rdf:about="http://w3id.org/rdfbones/ext/standards-si/DIMFrontalLeft">
        <rdfs:subClassOf rdf:resource="http://w3id.org/rdfbones/core#DataItemSpecification"/>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://purl.obolibrary.org/obo/IAO_0000136"/> <!-- 'is about' -->
                <owl:someValuesFrom rdf:resource="http://w3id.org/rdfbones/ext/standards-si/SectionCranialBonesAndJointSurfaces"/>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://purl.obolibrary.org/obo/IAO_0000136"/> <!-- 'is about' -->
                <owl:someValuesFrom>
                    <owl:Class>
                        <owl:intersectionOf rdf:parseType="Collection">
                            <rdf:Description rdf:about="http://w3id.org/rdfbones/ext/standards-si/Representation4States"/>
                            <owl:Restriction>
                                <owl:onProperty rdf:resource="http://purl.obolibrary.org/obo/IAO_0000136"/> <!-- 'is about' -->
                                <owl:qualifiedCardinality rdf:datatype="http://www.w3.org/2001/XMLSchema#nonNegativeInteger">1</owl:qualifiedCardinality>
                                <owl:onClass rdf:resource="http://w3id.org/rdfbones/ext/standards-si/LeftSideOfFrontalBone"/>
                            </owl:Restriction>
                        </owl:intersectionOf>
                    </owl:Class>
                </owl:someValuesFrom>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://w3id.org/rdfbones/core#groupingNumber"/>
                <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</owl:hasValue>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:subClassOf>
            <owl:Restriction>
                <owl:onProperty rdf:resource="http://w3id.org/rdfbones/core#activationSequenceNumber"/>
                <owl:hasValue rdf:datatype="http://www.w3.org/2001/XMLSchema#integer">1</owl:hasValue>
            </owl:Restriction>
        </rdfs:subClassOf>
        <rdfs:label xml:lang="en">DIM left part of frontal bone</rdfs:label>
    </owl:Class>

Advantages

• Specifications are defined on ontology level.
• Specifications are independent of the code defining the dataset.
• All elements can be reused unchanged in other ontology extensions.
• The data structure makes intuitively sense to ontology extension authors.
• Open for further types of specifications.

Disadvantages

• More ontology complexity.

[cuboideum]

Currently, I would opt for introducing new specification classes.

[zarquon42b]

How about the following: There is a generic ordering for elements in the Core ontology. If extensions want to refer to known classes but change the ordering they should do so by creating a copy of the ordering class but in their own namespace. E.g.

Bone_1 core_prefix:is_sorted 1
Bone_1 extension_prefix:is_sorted 5