Look at making the app namespace be a subclass of DOAP

[deiu]

There are currently terms in the solid-app vocab can do not need to be defined there and can be reused from existing vocabs.

[dmitrizagidulin]

Do we even use the solid-app vocab for anything?

[elf-pavlik]

How one makes distinction between app as general code base and particular deployment of that app?

Similar case in GoodRelations

• http://www.heppnetz.de/ontologies/goodrelations/v1#ProductOrService
• http://www.heppnetz.de/ontologies/goodrelations/v1#ProductOrServiceModel
• http://www.heppnetz.de/ontologies/goodrelations/v1#hasMakeAndModel

Same applies to Solid servers - 'powered by' particular codebase eg. ldnode but deployed somewhere by someone and offered as service.

In a way relevant to issue deploying apps to personal storage

I would also like to attribute the app (as model / code base) in data it generates using as:generator

[csarven]

First, I agree that there majority of the terms in this vocab can be reused from other vocabs. Second, this vocab was mostly experimental.. I don't think it is used in a way that's critical. Third, a single ns for solid stuff would suffice.

I suggest to drop this vocab altogether and all new terms should go into solid/terms ns.

@timbl @melvincarvalho , everyone, what do you think? Are you using anything here (https://github.com/solid/vocab/blob/master/solid-app.ttl) that's critical in your apps? If so, would you object to moving them to https://github.com/solid/vocab/blob/master/solid-terms.ttl - with preference to excluding anything that can be reused from other vocabs?

[csarven]

Also a reminder that in addition to having this repository for the Solid vocabs, one of the other reasons was to explore what's used and needed for the Solid-universe.

[csarven]

See also https://github.com/solid/vocab/pull/18/files which drops the obvious candidates: description, name, icon, homepage.