Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CSVW converter does not properly link data to author #12

Open
RinkeHoekstra opened this issue Aug 27, 2016 · 2 comments
Open

CSVW converter does not properly link data to author #12

RinkeHoekstra opened this issue Aug 27, 2016 · 2 comments

Comments

@RinkeHoekstra
Copy link
Contributor

It's a tricky thing to associate the nanopublication produced by the converter with the original author information of the CSVW schema file.

In principle, any author information in the schema is author information of the CSVW schema, but as we cannot know beforehand the URI that is generated for the nanopublication/assertion pair by the converters, it is practical to just take that author informaiton, and use it for the nanopublication as well (since the csvw conversion is a purely syntactic effort, we cannot really say there's any additional authorship involved: the authors of the resulting RDF are the same as the ones who devised the schema).

Still, currently the two are not connected. This is mainly because the CSVW schema files do not usually have a root resource with a URI (no @id tag in the root of the JSON).

Possible solutions:

  • replace the BNode with the generated URI of the nanopublication/assertion
  • owl:sameAs the BNode with the generated URI of the nanopublication/assertion
@rlzijdeman
Copy link
Member

@albertmeronyo sorry, to bother you with this, but @melvinroest was asking me whether 'we' still perceive this as a bug?

@albertmeronyo
Copy link
Member

@rlzijdeman Sorry I only see this now! I don't think this is much of a bug. At least in our experience nobody cared much about how authorship is modelled/serialised in the nanopub graphs? So I'd say it's rather a 'nice-to-have' :-)

@rlzijdeman rlzijdeman added enhancement and removed bug labels Dec 3, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants