@progval I am getting an error stating codeRepository and address should be the same. However, codeRespository was wrongly labeled . It's equivalent to hasSourceCode. address has not changed, not sure what this error is.

@moranegg adding a third column in the csv breaks the validator. So I added the rationale in a README file, following the example of CFF. I know you don't like this, but I don't have an alternative for now :(

Thanks for trying but...
It is impossible to maintain having two documents trying to say the same thing.
When I thought of a README, it was to add some metmetadata about the provenance of the crosswalk and not another mapping in .md format.

Let's try and find a more sustainable solutions even if we don't have the "good" info now.

please delete the README, and add this information not as a table but as remarks in an issue.

thanks again for your effort :-)

Then, shall we also delete the CFF readme?

However, codeRespository was wrongly labeled . It's equivalent to hasSourceCode.

It's not; code repositories contain source code, but source code can live outside repositories.

According to https://schema.org/codeRepository, this is a property of SoftwareSourceCode and links to a VCS; while hasSourceCode is a property of SoftwareApplication which links to a SoftwareSourceCode

Then, shall we also delete the CFF readme?

The CFF readme only gives rationale behind choices, not a copy of the table. You can do the same here

doap:repository is property linking doap:Projects with doap:Repositories. Both are object, not URLs.

doap:repository does not link to the URL, if we consider a doap:Project a SoftwareApplication, my proposal stands.

The comment about the extra readme is avoiding having one extra file fer crosswalk. Per @moranegg's comment I understand we want to avoid that

Oh wait, I get it. codeRepository and address should be the same is actually caused by you changing the order of entries, and the CI expects the first property to be codeRepository

@progval I have checked more of their examples, and here is evidence of my point (from https://github.com/ewilderj/doap/blob/master/examples/doap-doap.turtle):

:repository [
        :browse <https://github.com/ewilderj/doap/> ;
        :location <https://github.com/ewilderj/doap.git> ;
        a :GitRepository
    ] ;

The range of repository is supposed to be "SoftwareSourceCode", which is range of hasSourceCode. They also have the inverse property declares repositoryOf. I added location as mapping to schema: codeRepository

@progval ok, then pls let me know if you want me to revert the original order or not.

I would keep it ordered like this, it's easier to browse.

Thanks!

Yes please revert to the original order, this PR won’t match the script aggregating the mappings into the crosswalk table.

Ok, I will revert to the original unordered file when I get the chance

Hi @dgarijo we are moving forward with v4.0 .
If you want this PR to be in v4.0, please amend PR before January 10th 2024.
We will be very glad to have it in the next release if the files follows the codemeta crosswalk format.

I will amend the order this week.

I have reverted and removed the "comments" section. Since there is no other place where to put the rationale, I will do so here. The rationale has source property, target property and comments explaining the rationale:

• applicationCategory,category,exact match
• applicationSubCategory,category,broader than
• author,developer,broader than
• codeRepository,location, removed repository as mapping, because the range of repository is SourceCode, not the URL to the git repo. Location is used for that
• contributor,developer,"doap:documenter, doap:translator, doap:tester, doap:helper also map to this category"
• dateCreated,created,exact match
• description,description,doap:shortdesc also maps to description (narrower than)
• downloadUrl,download-page,possible map to doap:download-mirror as well. doap:file-release is narrower than downloadUrl (URL where to download the release)
• givenName,,Not mapped because this property is for persons
• hasSourceCode,repository,doap:repository is property linking doap:Projects with doap:Repositories
• installUrl,download-mirror,
• isSourceCodeOf,repositoryOf,inverse of repository
• issueTracker,bug-database,
• keywords,category,
• license,license,exact match
• maintainer,maintainer,exact match
• name,name,exact match
• operatingSystem,os,exact match
• programmingLanguage,programming-language,exact match
• publisher,vendor,
• referencePublication,blog,related
• runtimePlatform,platform,exact match
• softwareHelp,support-forum,developer-forum also maps. And doap:wiki
• softwareVersion,release,related. A release in doap links a project to a doap:Version. In schema.org this is more like the revision
• url,homepage,exact match. doap:old-homepage also maps to this propety (url is broader than). doap:location also maps to this property (for codeRepositories)
• version,revision,exact match

yay! checks passed this time. I hope this can be merged.

I'm not sure it is correct to map doap:repository to codemeta:hasSourceCode because the former links to a repository and the latter links to source code, which are not the same object (a repository contains source code); as you pointed out they are even formally defined as being different types.

Also, given that doap:location is nested inside doap:repository, you might want to replace the first line with codeRepository,repository/location

@progval I added your suggestions.
Since I don't really mind fighting the repository/repositoryOf mapping, I have removed it, in case it helps merging the PR before the next release.

@progval thanks!