#GDAL-2.2.0 (https://pypi.python.org/pypi/GDAL)

C:\Users\RD\Anaconda3\pkgs_rd\GDAL-2.2.0>pip install setup.py
Error: could not find the version that satisfies the requirement setup.py

Version: Python 3.6.1 !Anaconda 4.4.0 (32-bit) ! (default, date, time) [MSC v.1 900 32 bit (intel)] on win32

the licenses manged under https://github.com/edumbill/doap/tree/master/licenses can be replaced by SPDX licenses

SPDX provides unique license identifier, see http://spdx.org/licenses/
or here https://github.com/siemens/spdx-licenselist

Here is it:
https://github.com/taurenshaman/semantic-web/blob/master/data/usefulinc.com/doap.rdf

can you please deprecate the shortdesc property and introduce a new one (I suggest called summary) instead, that has a nice short name that is only one word (use owl:sameAs to indicate equivalence). I don't like properties that have multiple words in them, because RDF ontologies can never decide among themselves whether to use shortdesc, shortDesc or short_desc. It leaves my files looking a bit messy :P

I notice that DoaP support is on the advogato to-do list, so if you make this change before they implement it, most of the DoaP content online afterwards will use the new ontology.

The current System.IndexOutOfRangeException crash isn’t very welcoming.

This would allow project listings to display one or two selected screenshots, instead of just linking to a screenshots page.

With a freshly-installed mono, running make in either viewer/ or validator/ results in a compilation error, saying that Redland.dll can’t be found.

My distribution (ArchLinux) provides a redland package but nothing that would hint at mono bindings.

Is there any HTML version of the Doap ontology? The official website only has the XML document which is very difficult to read.

Hi!
The goals do state

Specifically not in scope for the first iteration is the description of software releases. Work on this can be investigated as a follow-up initiative

Has any work been done on this or is it already finished? I see that there is daop:release and doap:Version with a few properties, but they are not exactly sufficient for our purposes. We are looking into a linked data representation for managing automatic firmware updates of IoT devices. There might be multiple ways to install a version, like a fresh install or a small update or an update from the previous major version. Also each version might have different documentation.

All of these things don't seem to be covered by DOAP. What is the best practice here? Shall we roll our own ontology (in our own namespace), shall we combine multiple nearly-fitting ontologies? Can you suggest any good alternatives? Currently I found

• ADMS.SW 1.0 - which appears to be deprecated, and its successor seems to have a very different scope
• Codemeta, which draws from schema.org, has many more properties but doesn't even seem to distinguish between multiple release versions of the same application (or does it?)

I'm glad for any advise or pointers.

Doap namespace ( http://usefulinc.com/doap/ns/doap ) not found.

The Apache Software Foundation has hundreds of separate projects and many are
described using DOAP, with various automation using that data. The security team
was looking for ways to generate pages showing the
security contact for each of the projects and how to get hold of their
security updates. While the DOAP files would be the perfect place to
hold this data, there isn't suitable fields we can use for this.

Meanwhile other projects, such as securitytxt.org, are trying to build
up security-only metadata for projects (and websites) and have spent
time looking at what fields are most useful. But it seems to me like DOAP would be
a more natural place to describe this. I sent out a ping to Kjetil who recommended opening an issue here to discuss a proposal (and had some useful comments I've incorporated!)

One way of doing this:

Add a security contact

An address that anyone can use to report security issues they found
in the described project. Most likely this will be an email address
but it's possible it could be any URI

doap:security-contact mailto:[email protected]

(securitytxt also has fields for the key that can be used for encrypted
communication but I think that gets complex really fast (for example
some Apache projects require multiple keys with all used, other
projects are any used) and I believe these cases would be better
handled by pointing to a security policy)

Add a security policy

A link to the projects security policy which describes how they
deal with issues.

doap:security-policy https://www.apache.org/security/

(securitytxt also has a link for acknowledgements but I believe this is
better handled by the projects security policy). Ideally you'd also
have a link to a page listing the vulnerabilities themselves, but
this might be better handled by the security-policy page too.

or

As an alternative perhaps could this be handled by a doap:security-forum in a similar
way to the existing support-forum. I'm not familiar enough with SIOC
to see if that would be sufficient to describe all these fields correctly.

Currently there is Project, name, download-page, ArchRepository and foaf:mbox_sha1sum all in a same document, it would be nice to avoid having to lookup the schema every time we want to write something. :)

Hi
I was wondering if by any change you might have a sample of a valid doap project description in Json-LD ?
Thanks
Tibor

http://usefulinc.com/doap/ links to http://usefulinc.com/doap/ns/doap while it should be http://usefulinc.com/ns/doap

This would be pretty useful to display a friendly and memorable image to represent each project.

This would reference the canonical location for the documentation.

The wiki needs a DOAP example of a project expressed with microdata.

​Hello,

I'm a research intern at Software Heritage which collects the source code of software projects from a variety of origins. The same source code can be collected from different origins, each providing potentially complementary or conflicting metadata describing the project of which this source code is part, and the people that take part in it.

As I was researching different software ontologies I discovered the CodeMeta ​initiative, where a crosswalk table of metadata standards keeps different vocabularies.

I think it's important to integrate DOAP into the CodeMeta table and I'll be glad to do so,
but I would love your input on the translation between DOAP terms and CodeMeta terms:

Also, I was wondering ​if​ you have statistics about the usage of DOAP ​o​n Github or in general?

Cheers,
Morane

There are currently a few VCSes listed as children of the <repository/> property, but it’s missing many other ones, I think it would be better to have a <vcs>fossil</vcs> property inside of <repository/> and to put <browse/> and <location/> at that level too.

Since this is a breaking change, you should keep the legacy <ArchRepository/> et al as is for the time being.

I was reading the wiki and I noticed on the page for Project design that the the links were struck out and that there was a request for response if anyone had an existing copy. I also noticed that these linked items are in the Wayback Machine at the internet archive. See example link here: http://web.archive.org/web/20110216074234/http://www.ibm.com/developerworks/xml/library/x-osproj3/

With the proliferation of sites like github and the like, it would be good to have a field which points to the home location of the code.

The Content-Type header on this page should be application/rdf+xml; charset=utf-8 to let user-agents render it properly.

It would be good to know what the official MIME type of DOAP files/URLs is.

I'd think application/rdf+xml, but examples/redland-doap.rdf says:

Though it is recommended DOAP files start with Project as the document
element, they can be full fledged RDF files like this one is.

This would mean "normal" and "recommended" documents are no RDF and need a different MIME type.

The wiki should contain an example of how to link to DOAP documents from a normal HTML page.

If DOAP documents are RDF, it would be:

<link rel="meta" title="DOAP" type="application/rdf+xml" href="path/to/doap"/>

What if the DOAP document is no RDF?

Is the DOAP title needed or optional?

It would be useful to have a way to store the revision number associated with the release of a project.

See http://obi-ontology.org/page/Releases/How_OBI_is_versioned for our specific use case.

Thanks, Melanie

I've started to build a more generic (i.e. not just software) project-description ontology here
https://github.com/dr-shorthair/ont/tree/master/project
This was triggered by requirements coming out of the W3C DXWG.

@danbri suggested I let you know as there may be alignment potential in future.

ISO 639 has three relevant parts, 639-1, 639-2 and 639-3, each of them defining a different set of languages.

For best interoperability it is important to specify which one should be used.

Java apps can be ran on any OS with a Java runtime. There's no way to specify this within the os property apart from using a string literal like "Any"

The page at http://trac.usefulinc.com/doap/wiki/WikiStart describes (which is identical to http://trac.usefulinc.com/doap) gives a high-level overview of the DOAP project, but doesn't provide any obvious pointers to documentation. If there is a link to the documentation on that page, then it's not at all obvious.

Of course, one can download the RDF schema and work through that, or divine the structure from the (otherwise useful) examples, but while that's agreeably hardcore, it can't be said to be ... approachable.

viewer/doap.rdf and examples/doap-doap.rdf use GitRepository, while only GitBranch is defined in the schema.

A sensible solution would be #38.

This website is currently only available in plain text HTTP, making it susceptible to all kind of MitM attacks.

Here are all of the errors Firefox warns me about:

• The certificate is not trusted because the issuer certificate is unknown.
• The server might not be sending the appropriate intermediate certificates.
• An additional root certificate may need to be imported.
• The certificate is not valid for the name usefulinc.com.
• The certificate expired on November 16, 2016, 7:36 PM. The current time is August 20, 2017, 8:39 PM.

In addition, the HTTPS content points to an unrelated (?) root, with a default Apache2 page on Ubuntu and mailman archives.

A good solution would be to obtain a Let’s Encrypt certificate, automatise its renewal, and then configure Apache2 to only use the TLS version.

Most projects have one or more chat venues, where users can reach the maintainers, either for support or to help with development, translation, etc.

It would be useful to be able to list the purpose(s) there.

Japanese rdfs:comment’s for doap:tester and doap:language are tagged with language en, which makes them appear alongside English descriptions e.g. in the RDFS Explorer.

Hello! I've been building this tool over the past day or so and I think it's starting to take shape. I built in as part of a website redesign I'm working on, part of which I want to include machine-readable data of my projects. So I'd like to announce it here and see if you have any feedback.

It's a Ruby CLI application, installed from rubygems. The source code is available on my Gitlab instance.

$ gem install gitlab-to-doap
$ gitlab-to-doap nogweii/gitlab-to-doap

Running that produces the following XML:

<?xml version="1.0" encoding="UTF-8"?>
<Project xmlns="http://usefulinc.com/ns/doap#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:foaf="http://xmlns.com/foaf/0.1/">
  <name>Gitlab to DOAP</name>
  <shortdesc>Given a gitlab personal token (https://docs.gitlab.com/ce/user/profile/personal_access_tokens.html) and a gitlab project, produce a DOAP (https://github.com/ewilderj/doap/wiki) XML
file.</shortdesc>
  <homepage rdf:resource="https://code.aether.earth/nogweii/gitlab-to-doap"/>
  <created>2020-12-31</created>
  <repository>
    <GitRepository>
      <location rdf:resource="https://code.aether.earth/nogweii/gitlab-to-doap.git"/>
      <browse rdf:resource="https://code.aether.earth/nogweii/gitlab-to-doap/-/tree/main"/>
    </GitRepository>
  </repository>
  <download-page rdf:resource="https://code.aether.earth/nogweii/gitlab-to-doap"/>
  <bug-database rdf:resource="https://code.aether.earth/nogweii/gitlab-to-doap/-/issues"/>
  <programming-language>Ruby</programming-language>
  <programming-language>Shell</programming-language>
  <license rdf:resource="http://www.apache.org/licenses/LICENSE-2.0.html"/>
  <maintainer>
    <foaf:Person>
      <foaf:name>nogweii</foaf:name>
      <foaf:homepage rdf:resource="https://code.aether.earth/nogweii"/>
    </foaf:Person>
  </maintainer>
</Project>

Namely, I'd like to ask for your feedback on the output. I think I understood the specification correctly, or did I miss something? (Sadly there aren't that many real world uses I could easily find, except for the Apache Software Foundation and GNOME project. I've mostly modeled the features on those.) Is there anything you would like to be added?

Presuming it passes muster, I'll add it to the Generators wiki page.

This project was developed so long ago, it has no license.

I intend to apply the Apache 2 License to the work.

If you contributed, please indicate your assent in this issue:

@kjetilk @bufferoverflow @dachary @bergus @irl @pypingou

nothing to see

Hi,

we have just published a POM2RDF converter that traverses Maven POMs and outputs an RDF graph of project dependencies using DOAP and doap-deps vocabularies: https://hub.docker.com/r/atomgraph/pom2rdf
It can be used to generate project's dependency graph or a software bill of materials. Please give it a try if you have any projects using POMs.

We wanted to ask for a new doap:releaseOf property which would be the inverse of doap:release. We had to invent it because due to the direction of the recursive traversal it would be much more complicated to use doap:release.

currently all examples us RDF-XML representation of RDF

many people find turtle more readable for human
also recent development of json-ld brings another representation which i would expect becoming very popular

I would like to be able to describe a relationship between my projects and URLs for Jenkins jobs that build and test these projects.

Looking through the schema, i can't see a property for a project's forums, thought it has one for a wiki.

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

i see mention of work on mapping foaf:Person to schema:Person
maybe we could find useful mapping of doap:Project to schema:SoftwareApplication ?

related: #9

#docopt-0.6.2 (https://pypi.python.org/pypi/docopt)

C:\Users\RD\Anaconda3\pkgs_rd\docopt-0.6.2r>pip install setup.py

Error: could not find the version that satisfies the requirement setup.py
Version: Python 3.6.1 !Anaconda 4.4.0 (32-bit) ! (default, date, time) [MSC v.1 900 32 bit (intel)] on win32

Just a heads up - over at https://github.com/swi-prolog or http://swi-prolog.org there's talk going on of an ontology to describe prolog packs, and doap is prominently mentioned. Talk is happening on the mail list.

SWI-Prolog has a built in pack install function. If you want, say, the cowspeak pack you can install by querying

?- pack_install(cowspeak).

we can already get various meta-data about the pack, but are thinking having it in something more rdf-y would be good.

DOAP does not seem to include any properties to describe relationships (dependencies) between projects and/or their releases.

Greetings,

is the wepage http://usefulinc.com/ns/doap serving UTF-8 characters? I get some "fr">Détails "corruption" when viewing in a browser. <rdfs:label xml:lang="cs">Úložiště Git</rdfs:label> etc.

I just realized that I also raised this issue in #44 so I am going to close this.

Hi Ed,
I recently implemented [0] the DOAP vocabulary within Apache Any23 [1] and thought I would bring it to your attention.
The rationale behind this is that the vocabularies make up the core ontologies used by Any23 when parsing and extracting embedded structure from various document formats.
If you have some questions please head over to [email protected] mailing list.
All the best
Lewis

[0] http://svn.apache.org/repos/asf/any23/trunk/api/src/main/java/org/apache/any23/vocab/DOAP.java
[1] http://any23.apache.org

A Project generally consists of multiple versions, the latest stable release, zero or more future versions (beta, nightly, master, etc.) and zero or more previous releases, each of them with potentially different metadata.

It would make sense to have each of these versions linked in some way, at least from the stable release (which would then be the canonical URI, possibly as a symlink).

Since most of the metadata can change, it makes sense reuse the Project in each of them, and use an rdf:resource attribute to link them, that way we can keep the released versions immutable, and only modify master and the symlink.

A possible example would be:

<!-- my-project-0.2.rdf, also symlinked to my-project.rdf -->
<Project xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns="http://usefulinc.com/ns/doap#">
    <name>my-project</name>
    <!-- … -->
    <canonical-release rdf:resource="./my-project.rdf"/>
    <release>
        <Version>
            <revision>0.2</revision>
        </Version>
    </release>
    <release>
        <Version>
            <revision>master</revision>
            <other-release rdf:resource="./my-project-next.rdf"/>
        </Version>
    </release>
    <release>
        <Version>
            <revision>0.1</revision>
            <other-release rdf:resource="./my-project-0.1.rdf"/>
        </Version>
    </release>
</Project>

I dislike the names I chose for <canonical-release/> and <other-release/>, these should be subject to bikeshedding before being added to the specification.

These should be fixed to point somewhere else, I guess.