Maarten van Gompel

(See the above commit for an example)

@cboettig Thanks for your reaction! I understand the need to stay as close to schema.org as possible, and you're undoubtedly more at home in their conventions than I am. I...

I'd like to open up this discussion again as this is still a relevant point four years later. Based on the earlier discussion, I'd be in favour of having a...

Yes, you're right when you say that you need to know which of the inputs/outputs accepts/produces which files if you really want the specification to be actionable, this was indeed...

I just wanted to emphasize that I'm adhering to the reading suggested by @cboettig in my implementations (in [codemetapy](https://github.com/proycon/codemetapy) and derived tools), so I definitely wouldn't like to see this...

Thanks for your input! > can you outline a bit of the use case behind documenting generic entrypoints in the codemeta metadata? It's quite common for a software project, a...

> Also, knowing the API for a piece of software is different from knowing the specific deployment details (such as http URIs) for specific deployed instances of that software. We...

> One other note -- there is some tooling out there that works with the current release -- e.g., [codemetar](https://github.com/ropensci/codemetar) and [codemeta-generator](https://github.com/codemeta/codemeta-generator). I think we should try to keep those...

I agree repostatus terms provide an excellent vocabulary and we should recommend its usage, but it should not be a requirement and people should be free to use other vocabularies....

I'm looking for similar functionality and just stumbled upon the fact that this is not possible currently.