Linking source code to software applications (entrypoints and service endpoints aka SaaS) with regard for interface type about codemeta HOT 15 OPEN

@dgarijo Thanks! I have committed the initial proposal as it stands, we can continue from there next week!

from codemeta.

I have implemented the ideas from this issue in codemetapy and released a major new version today (2.0). It uses targetProduct to link source code to application instances and uses the extra types from https://github.com/SoftwareUnderstanding/software_types to describe their types.

Additionaly, I just released two new tools based on codemetapy for which this functionaltiy was needed. (I opened a pull request for inclusion on the website (codemeta/codemeta.github.io#39) as well):

• codemeta-harvester - A wrapper around codemetapy and other tools, provides a full automatic conversion pipeline to codemeta
• codemeta-server - A webservice/webapplication to search and browse codemeta (offers a SPARQL endpoint etc)..

A live demo of this ensemble of codemeta software can currently be found here: https://tools.dev.clariah.nl/ (mind that it's still in development).

from codemeta.

Hi all, I have added this issue as a discussion point towards v4.0 release.
I find it useful to have a property @reverse hasSourceCode.
In v3.0 we will be adding the hasSourceCode and I would like to have more participants to back providesApplication or counter semantic proposal to this reverse property.

Thank you @proycon for this proposal.

from codemeta.

@proycon thanks for the ping.
I like the categorization of software applications proposed, although adding providesApplication does not convince me because its overlap with targetProduct. In the end, it would confuse people to have 2 properties that are so similar. I also realized that there is no definition for this property above, so I don't think I know the difference myself.

I also like the part on entrypoints, which is crucial for usability. Sure, we should not go into describing all methods of an API, because that's what the spec do. But capturing metadata and examples at a basic level is crucial for discovery. In this regard, the work done by CWL is quite nice, although there is a risk to quickly run into a rabbit hole of complexity.

from codemeta.

Thanks for your reaction! If we indeed agree that targetProduct refers to the software product created by the source
code (as @cboettig wrote in #267, then I agree we can simply use that. Though there's ambiguity caused by schema.org's
description: Target Operating System / Product to which the code applies. If applies to several versions, just the
product name can be used." which might lead to an interpretation more akin to runtimePlatform.

from codemeta.

@proycon, yes, I think it can be misinterpreted. However, I think this could be clarified with documentation and examples.

What do you think is the best way of moving this forward? I think there are valuable things in this proposal to consider creating a profile for schema.org. Maybe this is too much for the current scope of codemeta.

This issue has been sitting for nearly two weeks without much interaction. Maybe we can create a separate repository and contribute towards defining application types, examples and minimal description for using them? I would like to incorporate some of this in the software description ontology, or the json-ld representation we create for software.

from codemeta.

yes, I think it can be misinterpreted. However, I think this could be clarified with documentation and examples.

Agreed, I think reusing and clarifying targetProduct as you suggested is the best way forward.

This issue has been sitting for nearly two weeks without much interaction. Maybe we can create a separate repository and contribute towards defining application types, examples and minimal description for using them? I would like to incorporate some of this in the software description ontology, or the json-ld representation we create for software.

Yes, I understand both codemeta and schema.org are fairly slow moving targets. I hoped to get some input from the wider codemeta community to see if the route I was suggesting was shared by enough people, but I do agree with moving forward as soon as possible and getting some actual definitions, examples and descriptions out there. We have practical applications we (CLARIAH project) want to realize with this in a mere matter of months. In fact, I already made a first attempt/draft today at formalizing some things (see CLARIAH/tool-discovery@f03b425). You're probably more experienced on this than I am so I'm very open to collaborating on this, we could indeed create a separate shared repository. Do you have a suggestion? Do we then go for an issue + pull request at schema.org directly after?

It would be also nice to align this with the (long) anticipated codemeta 3 release.

from codemeta.

@proycon regarding logistics:

• I would create a separate repo (I don't mind where it lives, ideally we can transfer it to codemeta when it's ready for review). Maybe we can call it the "software_types" profile.
• We should probably create a w3id for the profile (I can do that) to get the right context and content negotiation.
• The profile should (IMO) only be in JSON-LD + examples + doc (which is how it was done for codemeta).

Regarding the software_types profile:

For each type, I know a few efforts that tackle part of its representation. Hydra for APIs (https://www.hydra-cg.com/spec/latest/core/), function ontology / CWL (or even a little of software description ontology) for command line invocations, etc. The challenge is to avoid reinventing them, and summarize them in something that would be simple enough for a schema.org representation. Ideally, each type should have at least 1 unique property that motivates its addition. And several use cases.

The PR to schema.org I do not see it happening unless there is a significant community behind. But this initial discussion could serve to identify additional gaps that could lead to an addition in codemeta. And, until then, at least it would be helpful for us as an additional profile that we could support if interested (I see myself adding an additional export in somef to support extended types.

Thoughts?

from codemeta.

• I would create a separate repo (I don't mind where it lives, ideally we can transfer it to codemeta when it's ready for review). Maybe we can call it the "software_types" profile.

Sounds good to me! "software_types" covers the idea well so makes sense as a name. I don't care much where it lives either. Perhaps at your KnowledgeCaptureAndDiscovery group since it's close to your core business? I could also put it under CLARIAH alternatively. Transferring it to codemeta eventually would be good if the community agrees.

• We should probably create a w3id for the profile (I can do that) to get the right context and content negotiation.

Good idea

• The profile should (IMO) only be in JSON-LD + examples + doc (which is how it was done for codemeta).

Ok, so no RDF schema yet? I was looking a bit at how schema.org was handling things where all of the pending extensions seem to be accompanied by a turtle file.

Regarding the software_types profile:

For each type, I know a few efforts that tackle part of its representation. Hydra for APIs (https://www.hydra-cg.com/spec/latest/core/), function ontology / CWL (or even a little of software description ontology) for command line invocations, etc. The challenge is to avoid reinventing them, and summarize them in something that would be simple enough for a schema.org representation. Ideally, each type should have at least 1 unique property that motivates its addition. And several use cases.

Hydra looks promising, are there are already existing efforts mapping that to/from OpenAPI/Swagger? It'd indeed good to reuse as much as possible and reintroduce as little new vocabulary as possible. Simplicity is also a concern, we don't want to force any unnecessary complexity on users.

The PR to schema.org I do not see it happening unless there is a significant community behind. But this initial discussion could > serve to identify additional gaps that could lead to an addition in codemeta. And, until then, at least it would be helpful for us as > an additional profile that we could support if interested (I see myself adding an additional export in somef to support extended
types.

Yes, I was also worried a PR to schema.org might take too long so that sounds like a good approach, having it as an extra vocabulary that people can use. I think it's important it comes with practical implementation quickly, so it can be put to the test immediately. Your suggestion to implement it in somef sounds great; I'll do the same for codemetapy and the new codemeta-harvester which in turn leverages these tools, so then we already cover quite some ground.

from codemeta.

@proycon all right, I will create a repo and invite you so you we can iterate.

from codemeta.

@proycon I created https://github.com/SoftwareUnderstanding/software_types and added you as a maintainer. I do not have much time this week, but I would like to get to this next week. In the meantime, please commit your initial proposal, as I would like to preserve authorship as much as possible.

from codemeta.

Very cool @proycon! Do you annotate the link between target product and source code manually or automatically? I have not seen this captured in repo readmes, so I was wondering how it's done.

from codemeta.

@dgarijo Thanks! The link itself is captured manually (as software source code in a source repo by definition can't know exhaustively when/where it is deployed); codemeta-harvester reads a very simple YAML configuration file that points to the software source code and any service instances (see https://github.com/proycon/codemeta-harvester#usage-harvesting-metadata-for-various-projects). The end result is a codemeta file where the targetProduct is filled.

from codemeta.

from codemeta.

This issue is tagged v4.0.
We will be reviewing PRs for V4.0 by January 10th 2024.

Let me know if you want to propose something for v4.0.

from codemeta.