Biblink terms #3
Comments
|
On Thu, Mar 14, 2024 at 02:31:52AM -0700, Baptiste Cecconi wrote:
About the biblink terms, the usual convention in the web-semantics world is to have:
- capitalised terms for classes ;
- camel-case with lower case first letter for properties.
I am entirely relaxed on these syntax issues. So, if we decide we
won't do anything about bug #4, would you prepare a PR to that
effect? We'd still run it by ADS, but I don't expect they'd worry
much.
If, on the other hand, bug #4 adopts something external, it would
seem this would solve itself, right?
|
|
To come back to the proposed relations ( If you check the Datacite relation types, you can see that:
In our case, it is not true. If it were, ADS would already parse the reference and would list already. In the Datacite relation type vocabulary, the closest match would be I understand that the IVOA relation type vocabulary is excluding the Datacite meaning, but I would argue that we should align with them rather than adopt the same term with non-compatible definitions. I can propose a VEP, if needed. |
|
On Tue, Nov 05, 2024 at 06:10:45AM -0800, Baptiste Cecconi wrote:
says: `Cites` is used when `bib-ref` derives results from
`dataset-ref`.
If you check the Datacite relation types, you can see that:
- `Cites` means the `bib-ref` includes the `dataset-ref` in a citation.
In our case, it is not true. If it were, ADS would already parse
the reference and would list already.
I suppose the question is how you interpret the natural-language term
"includes ... in a citation". Does this actually mean, for Astronomy
and data, where there simply is little or no suitable citation
practice for datasets, "is listed in the printed article's reference
section"?
If we wait for that, I don't think we will see many <paper> Cites
<dataset> relationships ever.
If we, instead, interpet this as "The paper authors have expressed
*in some way* that their results use or take up dataset X" (and this
might eventually include whatever tech AAS or anyone else devises for
doing data citation, which I expect will *not* be "put it into the
references"), then I think we're almost good with Cites.
Of course, technically the citation statement comes from the
publisher rather the authors. But I'd trust the publishers to do the
right thing here, as I do when they put together the reference list
from what they receive from the authors.
In the Datacite relation type vocabulary, the closest match would
be `isDerivedFrom`. Following the Datacite words, using this term
would imply: `dataset-ref` is a source upon which `bib-ref` is
based. I think this is very close to what is meant by the current
text in the note.
We already have IsDerivedFrom in voresource/relationship_type. And
you are right, the term's definition *is* pretty close to what I
wrote in the note. I think I still like Cites better, because I
think this is what data citation ought to be about.
But I'd be about as happy with IsDerivedFrom. If you want, make a PR
against the note. Let's see what ADS has to say, and if they are ok,
I'd just merge it, fix DaCHS accordingly, and re-issue the note.
|
|
About the actual citation of data in papers, guess what: this already exists. I do it, and many colleagues do this too. Examples:
Those data citations are identified in ADS, and are listed in the datasources. There are other less formal citation, where a DOI is cited in a footnote, as in: https://doi.org/10.1051/0004-6361/202346144, which cites https://doi.org/10.24414/2qfw-tr95 in a footnote (that was a A&A policy at some point). However, those are explicit citations in the text (sometimes with an actual citation in the bibliographic references). Hence, I'd rather used the |
About the biblink terms, the usual convention in the web-semantics world is to have:
Hence, I would propose to rename the terms as:
BibRef(class)DatasetRef(class)Relationship(class)bibFormat(property)anchorText(property)cardinality(property)cites(property)isSupplementedBy(property)The text was updated successfully, but these errors were encountered: