Hi Kjetil,

> I'm the one who has done the semweb stuff at my.opera.com, and I'd like
> to express my support for what you're doing. Also, I think we will
> implement SIOC at my.opera.com as time allows, and I think we will
> support your W3C submission.

Thank you for the support and feedback to this project. :)

Regarding having little time - we plan to extend the feedback period by
approximately one week. This is in order to receive quality feedback
from a number of new participants (like you) who just joined. Will
announce this separately, but writing here so you know there is more
time to explore and comment.

> I can certainly see the value of the sioc:User/foaf:Person distinction
> in SIOC. It is the nature of community sites that we do not really know
> too much about the user who's publishing things, "on the Internet,
> nobody knows you're a dog" thus making foaf:Person alltogether rather
> inappropriate for community sites ;-) Also, it is difficult verify that
> a user isn't two or more persons or just a bot.

About verifying who is who - we shall leave that to the community sites
who are SIOC data providers. If someone really wants he will find
numerous reasons to doubt that something is a Person and will inflict
unnecessary complexity. These sites usually do not have a way to
distinguish if one is a real person or not (how do you know it's not
just a very good bot?) so we work from assumption that posts are
created by persons who have online accounts.

Note: a good thing is that sites themselves are interested to filter
out spammers so they may take care to at least verify an email. As for
sites that are spammers on purpose - you can't safeguard against that
(w/o web of trust).

If you want to avoid defining creator of content a foaf:Person you
might use a foaf:Agent instead, but there is little value in doing so.

> Now, I'm not arguing that we shouldn't use foaf:Person, quite the
> contrary. Using sioc:User as a wrapper around foaf:Person introduces
> some additional complexity, and I'm not sure it is worth it. Instead
> agents may just need to be a little more careful when making inferences
> based on data from a community site.

sioc:User allows to express the fact that content is created by user
accounts on a community site. there are properties that we may want to
express about the online account in particular.

foaf:Person holds all properties that are not account specific.

There is value in having sioc:User information - some persons may have
a number of accounts and there may be cases when you want to know what
has been written by a particular account (though in majority of cases
you might not care).

A solution we came up with recently is to assign a sioc:Post both
sioc:creator_of and foaf:maker - this way sioc:User does not act as
another layer "wrapping" foaf:Person and you can access FOAF data
directly. An exaple of this can be see on WordPress SIOC export [1].

[1] http://test.rdfs.org/blog/index.php?sioc_type=post&sioc_id=6

In cases when there is no user account (e.g., guest commenters on a
blog) you would use only foaf:maker.

> Also, I think it becomes quite difficult to know when to use the SIOC
> mbox and when to use the FOAF mbox, or both. Do I really need to use
> verify that the user is a person to use the FOAF properties, or?

No. SIOC properties are not there because of concerns of one being a
bot. It is rather a border case where we think a sioc:User may need it.
Properties sioc:email and sioc:email_sha1 are meant to link a user
account to a particular e-mail address it was registered with.

They are in the ontology to allow to retain this information for cases
when this is important, but in many cases you will not need them. When
in doubt always use foaf:Person and its mbox properties.

For this and other properties - maybe we need to improve their
description in the specification. That should avoid the confusion.
Please suggest any improvements that you see useful.

> Now, I suppose that the specification is not set in stone with the
> submission to the W3C, so this is perhaps a discussion that could
> proceed after the submission?

There is more time so we can discuss now. And after the submission is
done of course. The submission to W3C is not set in stone and we will
be making revisions to the specification as necessary, but it is harder
to change once submitted (requires another submission). Let's make it
good now, and improve later.

Uldis

--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---