dcmi / dctap

DC Tabular Application Profile
https://dcmi.github.io/dctap/
33 stars 10 forks source link

"Implicit" shapes #85

Closed tombaker closed 1 year ago

tombaker commented 1 year ago

@kcoyle In our discussion yesterday of the DCTAP vocabulary, I thought I heard someone suggest that, in effect, the uppermost "component" could be either a Shape or a Statement Constraint. I propose another way to see this.

In dctap-python I assumed that, for the sake of consistency in processing, the module should always output a Shape, regardless of whether that shape were explicitly declared. For example, when interpreting the most minimal DCTAP profile -- a simple list of properties -- the module should, in effect, infer the existence of a default shape. In dctap-python, the default name for that default shape is (drum roll...), default :-), but this can be configured to be anything else.

In other words, given a simple list of properties, the dctap module returns (here: in user-friendly syntax):

DCTAP instance
    Shape
        shapeID                  default
        Statement Template
            propertyID           http://purl.org/dc/terms/title
        Statement Template
            propertyID           http://purl.org/dc/terms/publisher
        Statement Template
            propertyID           https://schema.org/creator
        Statement Template
            propertyID           http://purl.org/dc/terms/date

I propose that we say that for DCTAP profiles about data for a single resource, a shape need not be declared, but that in accordance with the DCTAP model, the existence of a shape, as a grouping construct for the statement constaints, will nonetheless always be inferred.

We could add that this default shape can, in principle, be ignored by consuming applications downstream while pointing out that the existence of a shape - because it can always be inferred - simplifies processing.

philbarker commented 1 year ago

I think that makes sense, though hopefully most of the users who just want a simple property list will never know about it.

kcoyle commented 1 year ago

I agree with Phil but I am also having a devil of a time showing this as a diagram. I'm actually thinking that it will require at least two different diagrams, one showing a dctap with one or more actual shapes, and one showing a dctap without a defined shape. Once you put the shape in the diagram it's hard to show that it's "imaginary" in some cases.

tombaker commented 1 year ago

@kcoyle maybe use a dotted line for the box?

kcoyle commented 1 year ago

@tombaker I had that idea as well. Haven't tried it yet.

kcoyle commented 1 year ago

Add to cookbook - if no shape defined, implies a shape.

kcoyle commented 1 year ago

This is now in the primer: "In the most simple DCTAP, one that contains only one set of properties and constraints, that profile can be understood as representing a single, default shape. In this sense all DCTAPs can be said to be made up of at least one shape."