Add support for project dependencies #1
Comments
|
Diff is here: https://gist.github.com/1552777 |
|
I've also got a client that would like to use DOAP to organize and catalog their internal software projects, but they also require dependency tracking. What needs to happen to push this through? I may be able to put some of our developers on this if that would help move it forward. Just tell me what you need done. |
|
I think the main question would be: If the property in the patch is applied, does this solve your use cases? |
|
Yes, but I'm not wed to this particular patch. You and others in the DOAP community have already thought about dependencies a lot more than I have, so I'm not qualified to judge this patch with respect to the larger vision for DOAP. I just wanted to add my voice to those who've already expressed a desire for dependencies. |
|
Could you provide some examples on how you use this? |
|
How about dependencies on other resources? Like databases, or external/remote services? The diff states that the range is another Also, when creating a doap instance for a database or remote service it would be interesting to flag these. I found the "category" property, but the schema does not define a range for that. Is that a "trove" classifier? |
|
BTW, Toby Inkster has made a separate vocabulary for this: http://ontologi.es/doap-deps# |
|
@kjetilk thanks for that notification. I wonder if it would make sense to incorporate this vocabulary into DOAP? If Toby or you have interest, I would welcome there being another person or two keeping DOAP healthy. My current day job and spare time don't allow me much focus on it. |
|
Toby isn't much involved anymore either, but it seems I am in it for the long haul, but you can never know :-) So, I would happily accept co-maintainance of DOAP! I am divided as to whether it makes sense to incorporate doap-deps into DOAP proper, as already deployed code depends on it, and I tend to prefer small vocabularies that do one job and does it well, and we have that now, I think. But OTOH I realize that the world seems to agree that stuffing everything in one namespace is better (schema.org :-) ). |
|
@kjetilk just to tidy this thread up, I added you as a Collaborator in GitHub. We should probably figure out how to have a lightweight collaboration that works for us both. I know I have several outstanding tasks I need to do. |
|
Yep, that's the thing I need to do. Basically, it's on one of my servers and I need to run a Makefile. In the near term I can do that, but medium term we might need to find a way of hosting it that doesn't require it, or share your SSH key to me so you can do it too? Should probably take this conversation out of the issue… |
|
On Wednesday 22. February 2017 15.24.13 Edd Wilder-James wrote:
Yep, that's the thing I need to do. Basically, it's on one of my servers
and I need to run a Makefile. In the near term I can do that, but
medium term we might need to find a way of hosting it that doesn't
require it,
Yeah!
or share your SSH key to me so you can do it too? Should
probably take this conversation out of the issue…
Yeah, I can share my SSH key!
Perhaps you can email me at [email protected], so we can coordinate?
Kjetil
|
|
@tobyink I can't find the schema for doap-deps on that page that @kjetilk linked Do you have pans to re-host the Schema anywhere? Should we think about merging terms into DOAP? |
A need for expression of dependency information in DOAP has been expressed a couple of times on the mailing list [eg. 1,2]. As a start, the attached patch adds dependency support to the DOAP ontology definition. A property 'dependency' is added in the way that's (AFAICS) most advocated on-list. This means that a doap:Project can have a doap:dependency on another doap:Project.
Ported from Trac issues
The text was updated successfully, but these errors were encountered: