[doap-interest] doap:user?

[Benjamin Nowack]

On 03.01.2007 09:40:56, Thomas Vander Stichele wrote:
>You didn't address the main concern: the fact that it is a lot easier
>for a user of software to update a list of software he uses, than it is
>for a piece of software to update its list of users.  Using software is
>an active, unidirectional relationship, where the user initiates, not
>the software.
Hmm, I always have the impression that the damn software dictates ;)
More seriously, I think you're mixing UI and syntax here. And even then
[[
<#me> ex:software <#tool>
]]
should be semantically equivalent to
[[
<#tool> ex:user <#me>
]]
Both can easily be generated by a simple tool, no matter if you
maintain a list of software you use, or a list of persons that
use your software. Depending on use case and serialization format,
the size of the output data will vary, but there should be no effect
on the overall triple number or more important stuff like query speed.

>The link you paste only says that you are free to choose who links to
>who; this means that you should probably choose on other criteria, for
>example convenience.  It is definately more convenient - and correct,
>when changes are made - for the user to link to the software.
Convenience is always in the eye of the beholder. Think of a software
registry where people can add their names, for example. I don't see 
why one of the approaches should be incorrect.

Having said this, I'm fine with a doap:software prop as well (otherwise
I'd contradict my own argumentation ;), I just think that doap:user is
closer to doap's person and noun-role modeling principles. Patterns 
like doap:uses or doap:hasUser wouldn't fit as nicely. In that case
I agree with Uldis that the prop should be kept in some other vocab,
e.g. in a skill, experience, or preference term set.

Edd, would you be willing to consider the addition of any such
property at all? (No need to battle if there is nothing to battle
for anyway.. ;)

Cheers,
Benjamin

>
>Thomas
>
>
>
>