Create DCTAP vocabulary in namespace?

[kcoyle]

There are use cases in which it would be necessary to have the DCTAP vocabulary defined in a namespace, presumably in RDF. A mockup exists in the dctap github.

Use cases:

• export table to JSON-LD
• export table to RDF
• Others? please supply

This came up in the August 4 meeting.

[kcoyle]

Nishad's arguments for DCTAP elements in RDF:

• The main use case is to represent the profile in a semantic way. You can validate the semantics, running a sparql query. Or run ShEx or Shacl to validate.
• You can embed a profile within RDF datasets.
• It is easier to merge RDF data if you have the profile in RDF.
• People can extend it from other vocabularies.
• The profile is then semantically actionable.
• If you publish the namespace it is open.

[kcoyle]

Phil's concerns about a RDF vocabulary for DCTAP:

(Emails: 1, 2)

What it would mean to treat dctap elements as an RDF vocabulary in instance data? For example:

shapeID,shapeLabel,propertyID,mandatory
#bookShape,Book Shape,dc:title,True

as an RDF instance would that look like this:

<#bookShape> :shapeLabel "Book Shape" .

_:st :propertyID dc:title ; :mandatory ex:true .

The obvious thing that is missing, aside from Classes is any way to link the statement template to the shape. I had always assumed that would be something like

_:st :shapeID <#bookShape> ; :propertyID dc:title ; :mandatory ex:true .

The shapeID element is kind of doing double service as a placeholder for the ID of the shape that has the label under shapeLabel and as a property of a statement template. That has never entirely sat well with me. I don't think it affects functionality of the TAP in tabular form, but if I were defining it for RDF I see a difference between

> shapeID: [identifier] the object for properties such as shapeID (+ extensions such as description, open/closed etc, used in SHACL).

and

> shapeID: [property] the shape of which this statement template is part.

[kcoyle]

It seems to me that if we actually support an RDF version that we will need classes for Shape and Statement, so that these can be used as domains. ShapeID and shapeLabel would be in the domain of Shape, and the rest would be in the domain of Statement. (There may be some ranges we could define.) This doesn't solve other problems that @philbarker brings up.

There is no subject URI for the table as a whole, but that seems normal - this is where a system would provide an internally/or universal unique ID for the application profile. But because shapeID is likely to be a non-URI string, the ID itself can't be the subject of statements. Which means that we do not actually have an RDF-compatible identifier for the shape.

My other problem in thinking this through is with the "statement template" which has propertyID as its anchor. That one should be a URI of an existing property. But , as Phil points out, we lack a property that means "this shape has this statement." Or, if we reverse it: "this statement is part of this shape." There are the DC Terms "partOf" and "hasPart", I suppose.

So even if we add classes we still lack:

• an RDF-compatible identifier for the shape
• a property that has the shape as its subject and a statement as its object.

[kcoyle]

Another note: I played around with some sites that purport to be able to convert from JSON (not JSON-LD) to RDF and the results were pretty ugly. But it did show me that if we do want to support TAP-to-RDF without adding any properties to the vocabulary, that both the Shape and the Statement would be expressed within blank nodes. (Feel free to rebut this!) (Also to fix this attempt at turtle.)

<randomLocalID>
    [
     tp:shapeID "book" ;
     tp:shapeLabel "book" ;
         [
          tp:propertyID <dct:title> ;
          tp:valueDataType <xsd:literal> .
           ]
         [
           tp:propertyID <foaf:name> ;
           tp:valueDataType <xsd:literal> .
           ]
      ]

I'm guessing that if we add into the vocabulary a property for hasShape and one for hasStatement we might have more useful RDF. But do we really want to go there?