Re: DC TAP now a draft

Andrea,

"Shape" is something that we've struggled with,[1] and I'll pass along 
your comments. It really is a node in RDF. The node often (but not 
always) represents an entity in the metadata, like "person" or 
"address", that gets described by properties. One way to think of it is 
that the shape is an organizer for a group of properties. In SHACL terms 
the TAP shape is most likely a target node.

An example (a very simple one) would be useful here I think. Here's a 
shape with two properties:

Bookshape
     dc:title
     dct:creator

which could describe metadata that looks like:

<http://example.com/book123456>
  dc:title "DC TAP" ;
   dct:creator "Andrea".

Is some of the confusion from the fact that the shape is on the same row 
with the properties? In TAP, the shapeID is a value in a column for each 
of the properties for that shape:

Bookshape | dc:title
Bookshape | dct:creator

which says that properties dc:title and dct:creator are part of the 
Bookshape shape. (Some prefer not repeating the shapeID on each row 
because it is easier to read, and will assume that programs processing 
the CSV will read the blank cell as "same as above", much like Open 
Refine or other tools.)

There has also been a request that shapes be on their own row, which 
would allow you to express, for example, cardinality for the shape 
itself. So you would have:

Bookshape | (mandatory=true)
Bookshape | dc:title
Bookshape | dct:creator

or

Bookshape | (mandatory=true)
           | dc:title
           | dct:creator

However, we had trouble fitting that into a standard CSV without adding 
many more columns, e.g. cardinality columns for shapes could be 
functionally different from cardinality columns for properties. It is 
possible we were being too perfectionist, but that's how it worked out. 
Although not (yet) set in stone.

I'm totally available to chat if anyone wants to. Some of this is hard 
to do in email. And I will pass along your comments to the group.

kc
[1] https://github.com/dcmi/dcap/issues/73

On 4/29/21 2:25 PM, Andrea Perego wrote:
> Thanks a lot for the heads up, Karen!
> 
> Reading the documents, there is a point not completely clear to me,
> namely, what a "shape" is intended to be in DC TAP - in particular,
> when applied to an RDF vocabulary. Is it a class (in the RDF sense)? a
> constraint (in the SHACL sense)? both?
> 
> I think one of the reasons for my confusion concerns the examples,
> where shapes are denoted by literals (courses, tutors, etc.), whereas
> properties by IRIs from vocabularies as Dublin Core, FOAF, etc.
> 
> Andrea
> 
> On Thu, Apr 29, 2021 at 8:13 PM Karen Coyle <kcoyle@kcoyle.net> wrote:
>>
>> All,
>>
>> I wanted to let you know that the Dublin Core Tabular Application
>> Profiles specification is now a draft [1] on the DC site, and there is a
>> blog post with additional information and links. [2]
>>
>> We think that this draft is fairly stable, but we are now working on
>> various extensions including a manifest. The manifest document will not
>> be a single solution but examples of various ways that additional
>> information about the table can be expressed.
>>
>> What may be of interest to this group in that regard is that once we've
>> gotten further on our ideas for a manifest we intend to analyze
>> compatibility with the PROF vocabulary, and with the JSON context of CSV
>> on the web.[3]
>>
>> I also intend to try encoding DCAT-AP in TAP, although it is dauntingly
>> large so I may just do a portion. In any case, I'll get back to you when
>> I have more to report.
>>
>> Thanks,
>>
>> kc
>>
>> [1] https://www.dublincore.org/groups/application_profiles_ig/dctap_primer/
>>
>> [2] https://www.dublincore.org/blog/2021/draft_tap_specification/
>>
>> [3] https://www.w3.org/TR/tabular-data-primer/#handling-language-in-csvs
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net
>> http://kcoyle.net
>>
>>
> 

-- 
Karen Coyle
kcoyle@kcoyle.net
http://kcoyle.net

Received on Saturday, 1 May 2021 21:34:44 UTC