Re: DC TAP now a draft

Andrea, I chatted with Tom Baker and we have agreed that we need to do 
some better examples, ones that look more like "real data" than the 
mock-ups we have in the primer now. Hopefully the next version of the 
documentation will be clearer in terms of shapes with better examples. 
Thanks again for your comments - this is what helps us improve!

kc

On 5/1/21 2:33 PM, Karen Coyle wrote:
> 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 Thursday, 6 May 2021 16:10:58 UTC