Comments needed: Linking Post to a Person
Uldis Bojars
Could you please comment on this question:
what should sioc:Post point to as its creator ?
There are two main alternatives: (a) sioc:has_creator -> sioc:User; (b)
foaf:maker -> foaf:Person
Initially (and before usage of foaf:Person was added to SIOC) the
option (a) was intended. This can be observed in the RDF data [1]
generated by WordPress SIOC plugin. This option allows to keep the
information on which user account created the content.
If we do not link from sioc:Post to sioc:User then the user concept
does not become unneeded as such, but it is not used much either - as
nothing would then link to it apart foaf:Person via foaf:holdsAccount.
And we would loose the information that the content was created by a
particular account.
What do you think - is sioc:User useful and should we keep the
information on which account created a Post? For simple use of content
of sioc:Post that is not important but if you tried to import SIOC
content into an CMS (e.g., to make an RDF mirror of a community site)
then this info could be important.
Option (b) is illustrated by RSS export of Morten's blog [2].
There are more ways to point to a creator as well, e.g. use dc:creator
and point it to a rdf:resource as seen on Norm Walsh's blog [3].
We can also use both - point to a foaf:Person and a sioc:User. In
theory if we define the properties inbetween as IFPs then we can always
find foaf:Person if we know the sioc:User. Then the answer would be
(a).
(Hmmm, foaf:holdsAccount is not an IFP).
[1]
http://www.geospatialsemanticweb.com/index.php?sioc_type=post&sioc_id=115
[2] http://www.wasab.dk/morten/blog/feed/rdf
[3] http://norman.walsh.name/2006/07/31/flowers.rdf
Thanks,
Uldis
Jack Park
Uldis Bojars
- its rdfs:range is an agent (foaf:Agent, a supercalss of foaf:Person
and foaf:Group)
- its inverse property
- it is an owl:ObjectProperty
- ...
[1] http://xmlns.com/foaf/0.1/20050603.rdf
dc:creator points to a creator of a resource, but does not define more
formal semantics. Its value can also be a literal and it often points
to a string with a name of creator. (that's how i've seen it used in
RSS 1.0).
Maybe there are other differences as well.
Uldis
Benja Fallenstein
One reason to keep sioc:User is that screen names are associated with
accounts, not people, and users frequently refer to each other using
their screen names. For example, if a SIOC reader can't access the
screen name, it might render the following:
Jane Doe: True. So does it support Bluetooth?
Mike Smith: Hi! I was wondering whether this forum has a threaded view?
Ann Johnson: @coolbird: Yes! And we're proud of it! ;-)
while with access to the screen name, it could render the same conversation as:
coolbird: True. So does it support Bluetooth?
MSmith: Hi! I was wondering whether this forum has a threaded view?
ann_at_ericsson: @coolbird: Yes! And we're proud of it! ;-)
---
On the other hand, it would seem clearer to me to rename sioc:User ->
sioc:UserAccount and sioc:has_creator to sioc:creator_account or some
such. Just to keep people from getting too many misconceptions. :-)
- Benja
Benja Fallenstein
> formal semantics. Its value can also be a literal and it often points
> to a string with a name of creator. (that's how i've seen it used in
> RSS 1.0).
Not directly related to the question, but good to keep in mind to
understand this: If I understand correctly, the Dublin Core folks have
resolved that
_:post dc:creator "Benja".
implies that there is a resource _:x such that
_:post dc:creator _:x.
_:x rdfs:label "Benja".
and that the same is true for all other DC properties too (or most --
dunno whether they'd apply that to dc:date, for example...).
- Benja
Frederick Giasson
Just some thoughts because I have to go:
- For example, Some people will create an account on a forum, but
will not give real personal info (don't need to be related with the
account, a sort of anonymity).
- A single person can have different user accounts depending of the
service/community they use.
- I could care about content generated by a specific Person (foaf) in
a specific onliny community, and not about what he generated on other
online communities; in that case I would refer to his user account,
and not him personally.
Dunno if what I wrote make sense semantically, but quickly, I think
it makes sense to continue with the current method: sioc:User point-
to foaf:Person and foaf:Person point-to sioc:User (via foaf:
HoldAccounts).
I'll come back on the subject tomorrow if something else pop-up in my
mind.
Take care,
Salutations,
Fred
Alexandre Passant
I also think it makes sense to keep sioc:User , as we indeed must make
a distinction between the people and his account(s) on different
forums/blogs. So keeping
sioc:User rdfs:subClassOf foaf:OnlineAccount
seems good, even it UserAccount would be more appropriate to make a
distinction between the user (people) and its account.
BTW, we currently use sioc:name as a subproperty of foaf:name to
define the nick/account name of a user. I think we should subclass it
from foaf:accountName instead.
Regarding the link between post and a user, we've got the choice between:
(a) sioc:Post sioc:has_creator sioc:User / UserAccount
(b) sioc:Post foaf:maker -> foaf:Person
As Richard already mentionned [1], (b) seems to be the current foaf /
dc way to do.
Yet, if we keep (a) we could easilly get (b) with a rule as
_post sioc:has_creator _x
_x rdf:type sioc:User
_y rdf:type foaf:Person
_y foaf:holdsAccount _x
=>
_post foaf:maker _y
And we also keep a trace of which account have been involved in the
post / comment (which might be useful when dealing with online
commnities on some social aspect of them)
So I think (a) is more in the SIOC way, and do not interfer with
dc/foaf as we can infer the foaf:maker relationship.
Finally, a bit off topic, I've noticed that some exporters use
<sioc:has_creator sioc:email_sha1="..." rdfs:label="...">
especially for comments. I think using sioc:name would be better than
rdfs:label there.
Alex.
Benja Fallenstein
On 8/19/06, Alexandre Passant <al...@passant.org> wrote:
> BTW, we currently use sioc:name as a subproperty of foaf:name to
> define the nick/account name of a user. I think we should subclass it
> from foaf:accountName instead.
+1
> Regarding the link between post and a user, we've got the choice between:
> (a) sioc:Post sioc:has_creator sioc:User / UserAccount
> (b) sioc:Post foaf:maker -> foaf:Person
>
> As Richard already mentionned [1], (b) seems to be the current foaf /
> dc way to do.
>
> Yet, if we keep (a) we could easilly get (b) with a rule
[...]
I think this may be a case where we might want to recommend that
exporters simply use both. Being able to keep track of the account
used to create a post seems important -- but it would be nice if FOAF
tools would just work with the exported data, instead of having to add
a rule for SIOC.
Best,
- Benja
Alexandre Passant
On 8/19/06, Benja Fallenstein <benja.fa...@gmail.com> wrote:
> >
> > Yet, if we keep (a) we could easilly get (b) with a rule
> [...]
>
> I think this may be a case where we might want to recommend that
> exporters simply use both. Being able to keep track of the account
> used to create a post seems important -- but it would be nice if FOAF
> tools would just work with the exported data, instead of having to add
> a rule for SIOC.
>
You're right, we can use both in exporters.
BTW, we recently discussed on IRC how to manage people blog repliers
(and, more generally, different kind of post writers).
There are 2 uses cases:
- People need to register, in this case, we'll use the same as for "real" Users
- People just leave an email + a 'name' to post a comment
In this second use case, I don't think we should use sioc:User (and
its properties) as replier is not a *registered* user, which seems to
be the semantic of the User class.
I suggest we only use foaf:Person for them, with properties:
- mbox_sha1sum (to eventually smush data between different blogs /
accounts / people)
- foaf:name, foaf:nick or rdf:label. I'd prefer foaf:nick but as we
can't guess if that's a real name or a name, maye rdf:label is better
? (or maybe foaf allows a nick to be a real name ?)
So, for registered user who post / comment:
_post sioc:has_creator _user
_post foaf:maker _people
_user rdf:type sioc:User
_people rdf:type foaf:Person
_people foaf:holdsAccount _user
+ personal information in foaf:Person instance (and we could also keep
sioc:sha1sum in User class)
for unregistered
_post foaf:maker _people
_people rdf:type foaf:Person
+ personnal information in the foaf:Person instance
In the 1st case, both User and People could have a URI, while in the
second case, I think it will be easier to use blank nodes, and them
smush using sha1 (and we can also use it with really anonymous users,
if some forums / blogs / ... allow it)
Examples:
- http://apassant.net/blog/sioc.php?type=post&id=104 (post from registered user)
- http://apassant.net/blog/sioc.php?type=user&id=alex (user
information, with both FOAF and SIOC information). Regarding this, we
should also link to external foaf profile if available
- http://apassant.net/blog/sioc.php?type=comment&id=6709 (unregistered user)
open question:
- will we keep sioc:name + subclass/sameAs from foaf:accountName or
directly use foaf:accountName (+ deprecate sioc:name)
- what about foaf:name / nick / rdfs:label
Best,
Alex.
Frederick Giasson
Just a quick thought: what if an unregistered user leaving a message
on a forum or a blog doesn't want to leave his email or whatever
information? He want to be anonymous and the system allow him to.
Should it be interesting to create a new, special, type of class
called a sioc:Guest, or something like that, that would represent the
fact that a user can be anonymous, or a guest, without any personal
information available?
Salutations,
Fred
Alexandre Passant
Actually, in this case, the easiest way might be to not link the Post
to any foaf:maker or sioc:has_creator.
(I first talked about linking to a bnode from one if these types, but
if it has no property at all I'm not sure it makes sense)
Creating Guest type, if really anonymous, won't allow to link it to
foaf:Person (or creating link between 2 blanks nodes without
properties, not really useful).
Moreover, if we want to create this link, we'll have to create a new
property as we won't be able to use holdsAccount, and so, Guest cound
not be a subclass of User.
I'd prefer the 1st approach, a Post with no assigned maker / creator.
Of course, this is only my opinion :)
Alex.
> Salutations,
>
>
> Fred
>
>
>
> >
>
Frederick Giasson
> Actually, in this case, the easiest way might be to not link the Post
> to any foaf:maker or sioc:has_creator.
> (I first talked about linking to a bnode from one if these types, but
> if it has no property at all I'm not sure it makes sense)
>
> Creating Guest type, if really anonymous, won't allow to link it to
> foaf:Person (or creating link between 2 blanks nodes without
> properties, not really useful).
> Moreover, if we want to create this link, we'll have to create a new
> property as we won't be able to use holdsAccount, and so, Guest cound
> not be a subclass of User.
>
> I'd prefer the 1st approach, a Post with no assigned maker / creator.
>
> Of course, this is only my opinion :)
Yeah it make senses to me. I was not proposing something but only asking a
question :)
Take care,
Salutations,
Fred
Benja Fallenstein
The downside of having no assigned maker/creator is that you can't
tell from this whether the post was posted as "anonymous", or you
simply don't have all the triples...
I don't have a strong opinion on whether this is important enough to
warrant something special in the vocabulary, though.
- Benja
On 8/22/06, Frederick Giasson <fr...@fgiasson.com> wrote:
> > I'd prefer the 1st approach, a Post with no assigned maker / creator.
> >
> > Of course, this is only my opinion :)
>
> Yeah it make senses to me. I was not proposing something but only asking a
> question :)
Uldis Bojars
Alexandre Passant wrote:
> There are 2 uses cases:
> - People need to register, in this case, we'll use the same as for "real" Users
> - People just leave an email + a 'name' to post a comment
>
> In this second use case, I don't think we should use sioc:User (and
> its properties) as replier is not a *registered* user, which seems to
> be the semantic of the User class.
> I suggest we only use foaf:Person for them, with properties:
> - mbox_sha1sum (to eventually smush data between different blogs /
> accounts / people)
> - foaf:name, foaf:nick or rdf:label. I'd prefer foaf:nick but as we
> can't guess if that's a real name or a name, maye rdf:label is better
> ? (or maybe foaf allows a nick to be a real name ?)
As we discussed on #sioc it is not consistent then - in order to
retrieve information about creator of a post you may have to go 2
different ways. Also, a comment in SIOC is just a Post all this can
apply to posts in general.
I do not know how to solve this.
Option A: a pragmatical approach would be go via sioc:User anyway:
<sioc:has_creator>
<sioc:User>
<sioc:account_of>
<foaf:Person>
... person's properties ...
But it can be argued that this is redundant if we don't know anything
about a user. Also - if we describe comments this way each new comment
will result in a new blank node of a type sioc:User.
We can also define a rule (as suggested by [GNU]) that such a chain
(Post--has_creator--> User --account_of-->Person) means that
Post--foaf:maker-->Person.
Option B: identify a user with what we know
We have sioc:email and sioc:email_sha1 properties in SIOC. In most
cases we would use foaf:mbox of a foaf:Person, but we decided to keep
these properties in SIOC to be able to directly associate a mailbox
with a sioc:User. Then we can say:
<sioc:has_creator>
<sioc:User>
<sioc:email rdf:resource="..."/>
....
But this leaves a FOAF person out of the picture.
This may also require to define sioc:email as an IFP (inverse
functional property).
Option C:
Do as Alex says - use only foaf:maker if the user is not registered in
the system. Objection or suggestion - if we use this pattern and want
to be consistent we should use a foaf:maker for all posts.
> So, for registered user who post / comment:
> _post sioc:has_creator _user
> _post foaf:maker _people
> _user rdf:type sioc:User
> _people rdf:type foaf:Person
> _people foaf:holdsAccount _user
> + personal information in foaf:Person instance (and we could also keep
> sioc:sha1sum in User class)
>
> for unregistered
> _post foaf:maker _people
> _people rdf:type foaf:Person
> + personnal information in the foaf:Person instance
This is nice - you do use foaf:maker for all posts. :)
This looks like the best solution to me.
> In the 1st case, both User and People could have a URI, while in the
> second case, I think it will be easier to use blank nodes, and them
> smush using sha1 (and we can also use it with really anonymous users,
> if some forums / blogs / ... allow it)
Imagine a person using his FOAF file to identify him/her when writing a
comment... That'd be interesting. :)))
> open question:
> - will we keep sioc:name + subclass/sameAs from foaf:accountName or
> directly use foaf:accountName (+ deprecate sioc:name)
> - what about foaf:name / nick / rdfs:label
If we want to describe a login / account name of a sioc:User (subclass
of foaf:OnlineAccount) then we can use foaf:accountName directly. It is
often used together with a foaf:accountServiceHomepage to indicate the
site that the account is on (although in SIOC we should be able to find
this out from a sioc:Site)
Re. sioc:name - it is not needed for sioc:User then.
But it is needed to give a name to a Usergroup (and its scope should
also be extended to allow to name a Role).
Re. foaf:name / nick / rdfs:label - if we use a foaf:Person to describe
a creator of a comment we should probably use something more meaningful
than rdfs:label. Question - foaf:name or foaf:nick ?
Best,
Uldis
Benja Fallenstein
> We have sioc:email and sioc:email_sha1 properties in SIOC. In most
> cases we would use foaf:mbox of a foaf:Person, but we decided to keep
> these properties in SIOC to be able to directly associate a mailbox
> with a sioc:User. Then we can say:
>
> <sioc:has_creator>
> <sioc:User>
> <sioc:email rdf:resource="..."/>
> ....
>
> But this leaves a FOAF person out of the picture.
> This may also require to define sioc:email as an IFP (inverse
> functional property).
Actually, I think it might be a good idea to leave the FOAF person out
of the picture and *not* making sioc:email an IFP, in this use case.
If people comment without registration, you really have no knowledge
at all about whether the information they provide is correct, so it
might be best not to smush this information too naïvely...
Oh, come to think of it, sioc:email can't be an IFP anyway. sioc:Users
are associated with specific sites, and you can hardly require people
not to use the same e-mail for accounts on different sites ;-)
- Benja
Uldis Bojars
Benja Fallenstein wrote:
> On 8/22/06, Uldis Bojars <capt...@gmail.com> wrote:
> > We have sioc:email and sioc:email_sha1 properties in SIOC. In most
> > cases we would use foaf:mbox of a foaf:Person, but we decided to keep
> > these properties in SIOC to be able to directly associate a mailbox
> > with a sioc:User. Then we can say:
> >
> > <sioc:has_creator>
> > <sioc:User>
> > <sioc:email rdf:resource="..."/>
> > ....
> >
> > But this leaves a FOAF person out of the picture.
> > This may also require to define sioc:email as an IFP (inverse
> > functional property).
>
> Actually, I think it might be a good idea to leave the FOAF person out
> of the picture and *not* making sioc:email an IFP, in this use case.
> If people comment without registration, you really have no knowledge
> at all about whether the information they provide is correct, so it
> might be best not to smush this information too naïvely...
Agree that sioc:email should not be an IFP.
But just using a sioc:User (leaving or not a foaf:Person out) would
assert that the author of this post/comment has an online account on
this side. Which is a lie.
Shall we end up adding a sioc:Person to the ontology saying "similar as
foaf:Person but you better don't trust this information as you don't
know where it's come from"? Don't think so.
It boils down to the Semantic Web and trust, a generic problem. That is
true with all semantic web data out there - unless it is signed by
someone whom you trust (either directly or via web of trust) you should
not assume that this information is correct.
Maybe we can find/create a property (presumably outside SIOC) that says
"indentified by method X" or "identity assured by ..." in cases when a
User or a foaf:Person is identified on a system...
Uldis
Uldis Bojars
Some suggestions re. RDF/XML in these examples.
> Examples:
> - http://apassant.net/blog/sioc.php?type=post&id=104 (post from registered user)
> - http://apassant.net/blog/sioc.php?type=user&id=alex (user
> information, with both FOAF and SIOC information). Regarding this, we
> should also link to external foaf profile if available
> - http://apassant.net/blog/sioc.php?type=comment&id=6709 (unregistered user)
1) Use foaf:Document instead of a dc:Document. (I did not even find a
dc:Document, is there such a class? If so why does foaf:Document not
subclass from it?)
2) In some places you use an RDF/XML shortcut that results in object
properties having a literal value. E.g., foaf:homepage in the example
below becomes a literal (if I am not mistaken):
<foaf:maker foaf:nick="Richard Cyganiak"
foaf:mbox_sha1="5015291f2a6af9210f8d809b211db147d05cbadf"
foaf:homepage="dowhatimean.net/"/>
Same with rdfs:seeAlso in the example with post from a registered user.
Uldis
Alexandre Passant
On 8/22/06, Uldis Bojars <capt...@gmail.com> wrote:
>
> Hi Alex,
>
> Some suggestions re. RDF/XML in these examples.
>
> > Examples:
> > - http://apassant.net/blog/sioc.php?type=post&id=104 (post from registered user)
> > - http://apassant.net/blog/sioc.php?type=user&id=alex (user
> > information, with both FOAF and SIOC information). Regarding this, we
> > should also link to external foaf profile if available
> > - http://apassant.net/blog/sioc.php?type=comment&id=6709 (unregistered user)
>
> 1) Use foaf:Document instead of a dc:Document. (I did not even find a
> dc:Document, is there such a class? If so why does foaf:Document not
> subclass from it?)
Indeed, there's no dc:Document, don't know why I used it .
> 2) In some places you use an RDF/XML shortcut that results in object
> properties having a literal value. E.g., foaf:homepage in the example
> below becomes a literal (if I am not mistaken):
>
> <foaf:maker foaf:nick="Richard Cyganiak"
> foaf:mbox_sha1="5015291f2a6af9210f8d809b211db147d05cbadf"
> foaf:homepage="dowhatimean.net/"/>
>
> Same with rdfs:seeAlso in the example with post from a registered user.
You're right and I certainly make the mistake in other shortcuts, I'll
have a look at it.
Thanks for reporting this,
Alex.
> Uldis
>
> [ http://captsolo.net/info/ ]
>
>
> >
>
Benja Fallenstein
> But just using a sioc:User (leaving or not a foaf:Person out) would
> assert that the author of this post/comment has an online account on
> this side. Which is a lie.
Ok. Of course, if User is defined that way, your first option doesn't
work either -- only the third one would.
(Except if we add yet another class, which doesn't seem good...)
> It boils down to the Semantic Web and trust, a generic problem. That is
> true with all semantic web data out there - unless it is signed by
> someone whom you trust (either directly or via web of trust) you should
> not assume that this information is correct.
Ok, I'd like to reply to that, but before I do that, I should say that
I think you're probably right that it doesn't make sense to do
anything about this w.r.t. this use case ;-)
Given that, this is slightly off-topic, so I'll keep my reply brief :-)
I agree that this is a general problem with the semantic web.
I don't agree that requiring signatures is necessary for all but
really sensitive decisions: For most stuff, knowing which URI you got
some triples from should be sufficient. E.g., if I get some
information about you from your FOAF file at captsolo.net, for most
purposes I'll trust that it really came from you :-)
This model can be used with most RDF data today. Many RDF data stores
even allow aggregators to store which URI they got a triple from. We
haven't yet figured out how to make applications that practical use of
this, uh, provenance information is the academic term, but we get the
information from the data producers' side, so we are *able* to
experiment on the consumer side.
But if you have information originally asserted by *different* users,
and the only way your site exports it is collected together in one big
RDF graph, things get ugly.
Ideally, a SIOC graph should only assert things that your site
actually knows to be true. (Well, modulo perhaps some practicalities
like you don't *really* know whether one of your users isn't using
their e-mail account together with their spouse, which means foaf:mbox
is not true :-/)
For example, your site can assert as true:
* that there's a user account X in its system
* that a post Y has been posted using account X
* that it has sent a confirmation e-mail for X to e-mail address Z,
making it reasonably certain that (X foaf:mbox Z)
On the other hand, it doesn't know whether it's really true that--
* that the name of the person posting as X is really "Billy Gates"
* that a comment was really posted by the owner of the unverified
e-mail address A that the poster entered
On the gripping hand, it *can* assert that--
* the account holder of X claims that their name is "Billy Gates"
* the poster of the comment claims that their e-mail address is A
But since we can't verify the foaf:names for accounts, and we do *not*
want to define a new 'sioc:account_holder_claims_to_be_called'
property, we don't really have a way to solve this in SIOC anyway --
so it doesn't add that much of a problem that we can't do it for
non-registered users' comments, either.
------
Hm, I did write the above a bit more detailed than I intended, since
while writing it, I *did* have an idea how it could be solved. It may
be a bad idea, I'm not sure, but I figured I'd put it out there and
get your guys' opinions rather than not mentioning it at all :-)
Here goes: How about putting everything that your system cannot assert
into a separate RDF graph, and then pointing to it through
rdfs:seeAlso?
Give each registered user account a URI; let's say mine is
<users/benja>. Now, you can assert in your main SIOC file:
_:post sioc:creator <users/benja>.
<users/benja> foaf:accountName "befallen". # that's the user name my
university's network assigned me =)
<users/benja> foaf:accountOf [ foaf:mbox <mailto:benja.fa...@gmail.com> ].
<users/benja> rdfs:seeAlso <users/benja/foaf.rdf>.
In <users/benja/foaf.rdf>, you have,
<users/benja/foaf.rdf> foaf:maker _:benja.
<users/benja> foaf:accountName "befallen".
<users/benja> foaf:accountOf _:person.
_:benja foaf:mbox <mailto:benja.fa...@gmail.com>.
_:benja foaf:name "Benja Fallenstein".
Here, it's appropriate to include information asserted by me, not your
system -- namely, that my name is "Benja Fallenstein" -- because the
whole graph is information asserted by me, not you (even if your
server exports it for me).
This would also give a way to provide the information for comments by
non-registered users -- but it would require a separate RDF graph for
every such comment.
The problem with all this appears to me to be the gazillions of
requests for little RDF files that it would generate, a performance
problem for both server and consumer. :-( Suggestions about that:
* Still provide one big file with everything, but also provide the
smaller files which give you the provenance information, and be clear
that the big file smushes different people's assertions together.
* Have the clients get the information through SPARQL, not as plain RDF/XML.
Opinions?