Skip to content

Latest commit

 

History

History
142 lines (68 loc) · 4.79 KB

2021-08-24.srap_meeting_06.md

File metadata and controls

142 lines (68 loc) · 4.79 KB

DC SRAP meeting 6

Time: 2021-08-24, 16.00-17.00 CEST (14:00-15:00 UTC)

Place: Zoom, https://helsinki.zoom.us/j/64603883019?pwd=aUlCcWxrbEkwQkFsZHF1VFJ3UmlpUT09

  1. Opening of the meeting

  2. Appointment of the minutes taker (Osma will act as the chair)

  3. Approval of the agenda

  4. Minutes of the previous meeting (2021-08-10, Karen taking notes)

    1. DC SRAP meeting 5.docx - still need to be finalized and put into the meetings folder of the dc-srap repository
  5. Element-specific discussion

    1. Embargo date Alasdair has posted a draft for the Embargo Draft Range property.

    2. Status

    3. Presented at

    4. Affiliation

  6. Proposals for new SRAP elements

    1. Date retracted according to FaBiO, “The date on which something, for example a claim or a journal article, is retracted.”
    2. URL of code repository of a resource Freddy: “Sometimes the main descriptions of work are in code repositories like GitHub, which is not the same as the webpage. Inline to reuse/reproduce the work we can express the repository code RUL in the metadata of a resource.”
  7. Any other business

  8. Next meeting

    1. Scheduled for 2021-09-07
  9. Closure of the meeting

Present: Osma, Karen, Nishad

ACTION: Karen will post previous meeting to github; will look for anything that needs to be an issue. Let's try to use github for all comments.

From last meeting: Alasdair did a draft of the embargo item

Status: complicated - we should look at what people will reasonably do

Embargo: kc: "or a published standard of ISO" - not really true? osma: W3C says that it is a profile of ISO. LC one extends ISO of 2004, and that was extended into kc: OK, we can call them profiles! And people can use the open standards which are compatible Osma: make clear that approximate etc. actually comes from the standards, is not an extension ACTION: Osma will make small wording change; will make a vote proposal

Presented at

Can we use BIBO:presentedAt?

kc: is "presentedAt" the right term? use "conference"? osma: may not be a conference kc: what if you need to say place, date, etc.? osma: it can be a string or a resource; like the dataset, it's just a link kc: will people have a resource for the conference? use the website link? osma: website link isn't going to be reliable kc: dc usually doesn't go into detail (e.g. creator is wide open)

nishad: there is the question of decentralized publication - publications that are not a single file and can be linked with code, datasets, etc.

  * https://dokie.li
  * https://ruben.verborgh.org/publications/capadisli_icwe_2017/
  * https://ruben.verborgh.org/articles/

osma: there are lots of different types of publication - blog post, web page

nishad: w3c annotation model lets you have a way to cite documents and related materials; web site to run the code. so you can have an interactive graph or chart. Decentralized publishing will be important for the future

osma: how does this affect the metadata?

nishad: with semantic web you can define this as a scientific article or what type of page it is. We should consider this new type of publishing and cover that as well, since we are proposing new metadata elements

osma: SRAP is just for scholarly resources

nishad: there is no formal way to cite DC properties in formal metadata. WikiCite allows you to cite all kinds of documents. You can have updates to documents but the DOI doesn't change. You can also have a DOI for the original dataset, and every published version will have its down DOI

osma: this is out of scope for us; version?

kc: SRAP has status, but not version; status is the workflow, but Nishad is describing a more nuanced versioning

nishad: the article will be published somewhere, but may not be published yet but is still available and being read

osma: maybe propose "version"

kc: not sure how the metadata world defines these kinds of versions; how would be define what people should put in

osma: maybe this is a question about the subject of the triple; do a separate graph for each version. but how do you say that these are versions of the same thing? (kc: Brings up FRBR work, but better not to go there)

nishad: use dc specification as an example; each has a previous version, so it's like a chain; each version obsoletes the previous one

kc: DC terms has isVersionOf and hasVersion

osma: is there anything in SRAP that is different from dct:isversionof? 1. Not add to SRAP, but you can use because DC 2. Add to the table 3. Do a further specification

ACTION: do a github issue - Nishad

kc: may be tricky with Status, because they kind of overlap

Osma: github #19 - URL code repo of a resource; more description of resource is out of scope; #9 is a related dataset, subprop of dct:relation

kc: so, how far do we go? how many kinds of resources?