On 7 Apr 2007, at 20:32, Dan Brickley wrote:

> Here's one way of thinking about it. Do you want issue descriptions
> and management to transcend particular sites? eg. find out what
> someone has on their todo list across eg. sourceforge, google code,
> and company-internal issue trackers? if so, relate the issue to the
> flesh-and-blood, not their service logins. If the primary purpose
> is local to a specific installation, with cross-site aggregation
> and added extra, then mapping to user will be ok. Writing out some
> target SPARQL queries and seeing if they look useful and reasonably
> concise might be a way forward?

Thanks for helping me think about this. (jump to the end for a
summary of this post)

Mapping the bug databases of NetBeans and Sesame [1] has led me to
the following perspective.

Each of these bug databases has user account information which is
very minimal, or at least the part that one wished to make public is
very minimal due to privacy or spam issues. So a url identifying the
account of the user is perhaps as much as most people opening their
database may be comfortable giving away. It is certainly the least
risky thing to do. It may be the only information they have anyway.

On the other hand, as you mentioned in a previous mail on the sioc
mailing list, a foaf:Person can act as a personea ( a mask or role of
a person) so that it would be quite legitimate for each software
project to create a foaf:Person url for each user specific to that
project. This would then lead to a real active developer having a
large number of foaf urls identifying them; but these could then
later be related as owl:sameAs each other by the author if he so
wishes. But then we don't have much of an advantage in getting issues
related across sites , since every site would have given the user a
new url.

OpenId may end up changing this a lot though. I can imagine that in
the next few years, OpenId's will be very closely related to foaf
urls, and that quite quickly it will come to be common practice to
identify people like this across sites. People may indeed like to be
identified this way, as they can collect fame points for the work
they do across projects.

Now if we look at what a Issue consists of, for example

http://www.netbeans.org/issues/show_bug.cgi?id=8997

we can see that it is mostly a collection of Posts. sioc:Posts are
related to sioc:Users, so if we wish to use sioc:Posts then we should
really be working with sioc:Users too. (Mind you, I have seen it
stated nowhere that the sioc:User class is disjoint with the
foaf:OnlineAccount class, though it feels that it should.) This does
seem to tilt in favor of sioc:User, especially if one likes sioc. (I
am still just discovering it)

So I'll use sioc:User for the moment as shown on the UML diagram. But
keep in mind that it is the above reasoning that is leading me that
way. If I have forgotten to take something into account, or am not
thinking straight, , or am weighing priorities badly, let me know.
The above are really only partially explicit intuitions. We are still
at version 0.001 so everything is up for grabs. :-)

Well. I am still really shaky in that decision. So let me
recapitulate the pros and cons:

sioc:User
---------

+ works well with sioc:Post
+ reveals less info about the user
- creates an indirection with doap:Project relations (unless we
understand a foaf:Person and a sioc:User to be
non disjoint classes, in which case this need not be so)
? what advantages could one gain from the other sioc relations in a
bug ontology? The sioc:Role class could be useful I suppose (but how?)

foaf:Person
-----------

+ could work better in the future where all sites use open id style
urls to identify people
+ foaf:Person is probably the most widely used class on the web, most
ontologies work with
- does not work so well with sioc:Post

? how else does that link in with other sioc elements?

baetle:Person
-------------

+ leave the problem for someone else to solve
+ would allow one to create relations on baetle:Person that are
relevant only to bug databases and allow it to overlap both
foaf:Person and sioc:User
- would make queries on baetle:Person more complex if they required
information about sioc:User or foaf:Person
- may not work so well with sioc:User or sioc:Post (unless
foaf:Person and sioc:User are non disjoint)

Henry

[1] http://groups.google.com/group/baetle/browse_thread/thread/
3185be11a02a8e77

> Dan
>
>
> On 07/04/07, Henry Story wrote:
> Should baelte:reporter relate baetle:Issue(s) to foaf:Person or to
> sioc:User ? It's not so obvious in some ways, since a sioc:User is a
> subclass of a foaf:OnlineAccount, and it seems a bit weird to make an
> online account responsible for fixing bugs.
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev?hl=en
-~----------~----~----~----~------~----~------~--~---