Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add a way to reference other versions of the Project #52

Open
linkmauve opened this issue Aug 21, 2017 · 1 comment
Open

Add a way to reference other versions of the Project #52

linkmauve opened this issue Aug 21, 2017 · 1 comment
Assignees

Comments

@linkmauve
Copy link
Contributor

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.

@ewilderj
Copy link
Owner

If I read this right, this is related to both #80 and #74 -- do you agree? I think a little design document might be the right thing to address all three of these issues. I'm not 100% clear on the motivations expressed in this issue.

@ewilderj ewilderj self-assigned this Jun 11, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants