Contribution from UMU to SIOC Ontology

2006, September 12 - 09:00 — andresmo

These are the comments, questions and suggestions that have come up as
a result of our analysis of the SIOC ontology. We have generated
comments for a number of main concepts in the ontology. The following
is a list of the concepts which received some comments from our side:

·Forum
- It is declared that a forum will have a moderator or
administrator, but how is this relation represented in the model? Does
it come implicitly by a concrete role played by a subscriber of the
forum?

- The meaning of "scope_of" property is not quite clear.
Does it mean that a forum is only visible to a fixed type of role? Or
is it interesting to a specific type of role?
Another possibility that we have thought of is that this property tries
to represent the administration relation that we have mentioned in the
previous point, but it seems a bit weird, because is a user who
moderates a Forum, not a role.

- A forum could be devoted to a certain group of users, but
how is represented the relation among forums and groups of users, that
is to say, how do you associate a group of user with a forum? It seems
that neither a direct relation nor an indirect one model this fact.

·Post
- "Content" and "description" properties have got the same
semantic meaning; it seems that there is no difference between them. We
have read in [1] that currently it is being considered the idea of
inserting AtomOWL to represent the content of a post, which sounds to
be a good choice. So we suppose that these two properties will be
reduced to one of this AtomOWL type.

·User
- As in Forum class, we can't see a relation that allows
representing that a user is moderator of a forum or site, as is stated
in the specification. That is to say, we miss a property that relates a
user with the administrator role with a forum, and its inverse (a forum
that is administrated by a user), like "subscriber_of" property does.

·Usergroup
- Should "usergroups" have a role? It is not explicitly
mentioned in the specifications, and there isn't any relation between
this class and the "Role" class that could state this situation. For
example, a group of users could be defined as banned users or as
administrator of a site. Then, users could be added to these groups
without the necessity of specifying their roles, as they could be
inferred from the group where they belong to.

·About "topic" property
We think that "topic" property should be modelled as a class
and not as a property, since topic is a sufficiently important entity
to having its own properties: category, description, keywords, impact
factor, etc.

[1] http://rdfs.org/node/128

Best Regards,
Andrés Muñoz
University of Murcia, Spain

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

Developers

2006, September 13 - 07:56 — Axel Polleres

comments on the current submission document...

Dear all,

Here some comments on the current version of the SIOC document at

http://rdfs.org/sioc/spec/
I start with editorial comments and then give more fundamental
issues/questions:

Editorial:

1) First of all, the link http://rdfs.org/sioc/ which is mentioned
several times seems to be broken!

2) "The specific contents of the SIOC ontology are detailed in the SIOC
namespace document."

You mean SIOC project page or http://rdfs.org/sioc/ns here? (that is one
of the broken links).

makeing -> making

3) "an attribute of an sioc:Post"
--> "an attribute of a sioc:Post"

====================================

1) I am not sure whether I understand the *Role* concept correctly, but:

Obviously a role is a ternary relation which is something nasty to
express in OWL and RDF. One could mention that the complete
axiomatization of this concept is not expressible in OWL.
In particular there seems to be a problem with the current Role definition:

A role might be available in several forums (scope_of), a user might
play several roles (function_of), but, as for the current ontology, it
does not seem you can express that a user plays a particular role in a
particular forum (for this you'd need to reify the "roleplay" e.g. with
a bnode

Otherwise, if you want to restrict roles to belong to exactly one forum,
then you need to declare scope_of functional.

2) maybe stupid question: What is 'vanilla' XML?

3) Reuse: I can go through this later in more detail, (actually, I
suggested to Stefan/Uldis already to add an own section which clarifies
the relation to other vocabularies), but obviously there are many
overlaps with existing vocabularies:
sioc:User vs foaf:Agent (which is probably more appropriate than
foaf:Person) is already being discussed on this list, but also
foaf:depiciton, foaf:mbox, etc. all seem to be reinvented in a sense.

4) Probably, there are also some overlaps with the RDF-version of RSS?
So, I think it would really be nice to have such an overlap section,
which justifies the reinvention or at least add
equivalence/subclass/subproperty axioms in a related ontologies part of
the spec.

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, September 14 - 16:39 — terraces

comments on the current submission document...

Hi all,

On 9/12/06, Axel Polleres <droxel@gmail.com> wrote:

1) I am not sure whether I understand the *Role* concept correctly, but:

Obviously a role is a ternary relation which is something nasty to
express in OWL and RDF. One could mention that the complete

axiomatization of this concept is not expressible in OWL.
In particular there seems to be a problem with the current Role definition:

A role might be available in several forums (scope_of), a user might
play several roles (function_of), but, as for the current ontology, it

does not seem you can express that a user plays a particular role in a
particular forum (for this you'd need to reify the "roleplay" e.g. with
a bnode

Otherwise, if you want to restrict roles to belong to exactly one forum,

then you need to declare scope_of functional.

I think it could be nice at the moment to remove Role from SIOC core and add in the specs a section about SIOC extensions, mentionning that SIOC aims to be a modular ontologies, with Role, Versionning ... extensions. Role is a complex approach as you mention, so I think it would be nice to get it in a separate way - which also will let us think more deeply on it, and that could evolve while the core of SIOC won't change.

3) Reuse: I can go through this later in more detail, (actually, I
suggested to Stefan/Uldis already to add an own section which clarifies

the relation to other vocabularies), but obviously there are many
overlaps with existing vocabularies:
sioc:User vs foaf:Agent (which is probably more appropriate than
foaf:Person) is already being discussed on this list, but also

foaf:depiciton, foaf:mbox, etc. all seem to be reinvented in a sense.

4) Probably, there are also some overlaps with the RDF-version of RSS?
So, I think it would really be nice to have such an overlap section,
which justifies the reinvention or at least add
equivalence/subclass/subproperty axioms in a related ontologies part of

the spec.

Such a section, with mappings, could be interesting. Yet, most of the
foaf properties have been removed from SIOC, and indeed put
back in the FOAF Person which holds the sioc:User.

(BTW, User and Agent are not the same kind of object. There's a holdsAccount relationship between them, so sioc:User is not an foaf:Agent, but a foaf:Account)

Best,

Alex.

--
Dr. Axel Polleres
email: axel@polleres.net
url: http://www.polleres.net/

--~--~---------~--~----~------------~-------~--~----~

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

2006, September 14 - 16:39 — Axel Polleres

comments on the current submission document...

Alexandre Passant wrote:
> Hi all,
>
> On 9/12/06, *Axel Polleres* >
> wrote:
>
>
> 1) I am not sure whether I understand the *Role* concept correctly, but:
>
> Obviously a role is a ternary relation which is something nasty to
> express in OWL and RDF. One could mention that the complete
> axiomatization of this concept is not expressible in OWL.
> In particular there seems to be a problem with the current Role
> definition:
>
> A role might be available in several forums (scope_of), a user might
> play several roles (function_of), but, as for the current ontology, it
> does not seem you can express that a user plays a particular role in a
> particular forum (for this you'd need to reify the "roleplay" e.g. with
> a bnode
>
> Otherwise, if you want to restrict roles to belong to exactly one
> forum,
> then you need to declare scope_of functional.
>
> I think it could be nice at the moment to remove Role from SIOC core and
> add in the specs a section about SIOC extensions, mentionning that SIOC
> aims to be a modular ontologies, with Role, Versionning ... extensions.
> Role is a complex approach as you mention, so I think it would be nice
> to get it in a separate way - which also will let us think more deeply
> on it, and that could evolve while the core of SIOC won't change.

I think it is not necessary to remove it, but it wouldbe nice to have
the issue resolved in a clean way.

> 3) Reuse: I can go through this later in more detail, (actually, I
> suggested to Stefan/Uldis already to add an own section which clarifies
> the relation to other vocabularies), but obviously there are many
> overlaps with existing vocabularies:
> sioc:User vs foaf:Agent (which is probably more appropriate than
> foaf:Person) is already being discussed on this list, but also
> foaf:depiciton, foaf:mbox, etc. all seem to be reinvented in a sense.
>
>
>
> 4) Probably, there are also some overlaps with the RDF-version of RSS?
> So, I think it would really be nice to have such an overlap section,
> which justifies the reinvention or at least add
> equivalence/subclass/subproperty axioms in a related ontologies part of
> the spec.
>
>
>
> Such a section, with mappings, could be interesting. Yet, most of the
> foaf properties have been removed from SIOC, and indeed put back in the
> FOAF Person which holds the sioc:User.
> (BTW, User and Agent are not the same kind of object. There's a
> holdsAccount relationship between them, so sioc:User is not an
> foaf:Agent, but a foaf:Account)

Any volunteer to join me to give it a go?

axel

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, September 13 - 07:56 — Cloud

comments on the current submission document...

Dear all -

Just on the URL point, we've just the pages to a new server today so
expect some redirects!

John.
--
Axel Polleres wrote:
> Dear all,
>
> Here some comments on the current version of the SIOC document at
>
> http://rdfs.org/sioc/spec/
> I start with editorial comments and then give more fundamental
> issues/questions:
>
> Editorial:
>
> 1) First of all, the link http://rdfs.org/sioc/ which is mentioned
> several times seems to be broken!
>
> 2)
.
.
.

2006, September 14 - 16:39 — andresmo

comments on the current submission document...

Hi John,

Thank you very much for your interest in our comments and for your
quick answer. I think that your comments about our ideas are quite
good, and give us food for thought in these issues. So, these are our
opinions about your comments:

> 1. Removing the domain / range constraints on Role (at the moment the
> domain is User and the range is Forum). This would allow the range to
> be User, Usergroup and the range to be Forum, Site, Community etc.)

I agree with this point, if we think that a group of users needs to
have a Role (for example, if we only want to give access to a forum to
a user who belongs to a specific group).
What I'm thinking about is whether to remove the domain/range
constraints of Role completely, or create two new superclasses, one for
objects that are able to "manage" other objects (e.g. "Manager"
class) and the other for objects that are managed (e.g. "Managed
Element").
Consequently, the range of "function_of" would be Manager and for
"has_scope" would be Managed_Element. Obviously, User and Usergroup
would be subclasses of Manager and Forum, Site, etc. would be
subclasses of Managed_Element.

The latter choice would maintain some constraints on Role, but perhaps
may introduce some confusion, because a "normal" user that is not
managing any element belongs (indirectly) to the Manager class, so this
idea may be refined. What do you think about it?

> 2. Adding has_moderator and has_administrator properties to Forums and
> Sites respectively.

Right, because the relation

User -> has_function -> Role (of whatever type, e.g.
Moderator) -> has_scope ->
Forum

now has sense to me, but the opposite relation seems a bit tricky,
because to determine the forum's moderator, first you have to find
out if this role applies to the forum, and then look for the user that
has got that function in that forum (a bit long path, perhaps).

So the shortcuts give an instant access to the moderator or
administrator. The problem may be how to state that the previous
relation User->Role->Forum has its inverse in these shortcuts.

And finally, taking up again the topic issue, we would like to see an
example of this property working with the SKOS concepts, so that we can
clarify ourselves if this mechanism is enough to fulfil our ideas. So,
if you could suggest some example of this, it would come to help us.

Best Regards,
Andrés

2006, September 14 - 16:39 — Cloud

comments on the current submission document...

Hi again -
> Consequently, the range of "function_of" would be Manager and for
> "has_scope" would be Managed_Element. Obviously, User and Usergroup
> would be subclasses of Manager and Forum, Site, etc. would be
> subclasses of Managed_Element.
>
>
The only problem I see here (a good idea by the way) is that some roles
will be more passive than active, i.e. you may have a role that you are
a member of a community or a forum, without actually managing anything...

> So the shortcuts give an instant access to the moderator or
> administrator. The problem may be how to state that the previous
> relation User->Role->Forum has its inverse in these shortcuts.
>
>
Yes, really the Role can describe the extra shortcut properties we don't
(or won't) include in the ontology.
>
>
> And finally, taking up again the topic issue, we would like to see an
> example of this property working with the SKOS concepts, so that we can
> clarify ourselves if this mechanism is enough to fulfil our ideas. So,
> if you could suggest some example of this, it would come to help us.
>
>
I hope Uldis can do this :)

Thanks again,

John.
--

2006, September 14 - 16:39 — Axel Polleres

comments on the current submission document...

John Breslin wrote:
> Hi again -
>
>>Consequently, the range of "function_of" would be Manager and for
>>"has_scope" would be Managed_Element. Obviously, User and Usergroup
>>would be subclasses of Manager and Forum, Site, etc. would be
>>subclasses of Managed_Element.
>
> The only problem I see here (a good idea by the way) is that some roles
> will be more passive than active, i.e. you may have a role that you are
> a member of a community or a forum, without actually managing anything...

I am not sure whether I understand this correctly... does this solve the
roleplay issue I raised in my previous mail. Still I don't see how you
model the ternary relation:

A plays role R in forum F

without reifying this ternary relation (over a bnode, for instance...)

thanks for clarification,

axel

>>So the shortcuts give an instant access to the moderator or
>>administrator. The problem may be how to state that the previous
>>relation User->Role->Forum has its inverse in these shortcuts.
>>
>>
>
> Yes, really the Role can describe the extra shortcut properties we don't
> (or won't) include in the ontology.
>
>>
>>And finally, taking up again the topic issue, we would like to see an
>>example of this property working with the SKOS concepts, so that we can
>>clarify ourselves if this mechanism is enough to fulfil our ideas. So,
>>if you could suggest some example of this, it would come to help us.
>>
>>
>
> I hope Uldis can do this :)
>
> Thanks again,
>
> John.
> --
>
> >
>

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, September 14 - 16:39 — andresmo

comments on the current submission document...

Hi Axel

> >>Consequently, the range of "function_of" would be Manager and for
> >>"has_scope" would be Managed_Element. Obviously, User and Usergroup
> >>would be subclasses of Manager and Forum, Site, etc. would be
> >>subclasses of Managed_Element.
> >
> > The only problem I see here (a good idea by the way) is that some roles
> > will be more passive than active, i.e. you may have a role that you are
> > a member of a community or a forum, without actually managing anything...
>
> I am not sure whether I understand this correctly... does this solve the
> roleplay issue I raised in my previous mail. Still I don't see how you
> model the ternary relation:
>
> A plays role R in forum F
>
> without reifying this ternary relation (over a bnode, for instance...)
>

I think that you don't need to use a bnode to represent this relation.
For example, suppose two instances of User class, "Andres" and "Axel".
Now, we have two Forum instances, "The Beatles Forum" and "Axel_Blog".
Suppose that you want to state that "Andres" is admnistrator of the
"The Beatles Forum" and Axel administrates "Axel_Blog".

So, you may create one instance of Role class, called "Admin1", which
"function_of" property has the value "Andres" and "has_scope" is "The
Beatles Forum". On the other hand, another Role instance called
"Admin2" would have "Axel" as "function_of" and "Axel_Blog" as
"has_scope".

Finally, these relations are represented without using a bnode.

Hoping this helps,

Andrés

2006, September 14 - 16:39 — Axel Polleres

comments on the current submission document...

andresmo wrote:
>
> Hi Axel
>
>
>
>>>>Consequently, the range of "function_of" would be Manager and for
>>>>"has_scope" would be Managed_Element. Obviously, User and Usergroup
>>>>would be subclasses of Manager and Forum, Site, etc. would be
>>>>subclasses of Managed_Element.
>>>
>>>The only problem I see here (a good idea by the way) is that some roles
>>>will be more passive than active, i.e. you may have a role that you are
>>>a member of a community or a forum, without actually managing anything...
>>
>>I am not sure whether I understand this correctly... does this solve the
>>roleplay issue I raised in my previous mail. Still I don't see how you
>>model the ternary relation:
>>
>>A plays role R in forum F
>>
>>without reifying this ternary relation (over a bnode, for instance...)
>>
>
>
> I think that you don't need to use a bnode to represent this relation.
> For example, suppose two instances of User class, "Andres" and "Axel".
> Now, we have two Forum instances, "The Beatles Forum" and "Axel_Blog".
> Suppose that you want to state that "Andres" is admnistrator of the
> "The Beatles Forum" and Axel administrates "Axel_Blog".
>
> So, you may create one instance of Role class, called "Admin1", which
> "function_of" property has the value "Andres" and "has_scope" is "The
> Beatles Forum". On the other hand, another Role instance called
> "Admin2" would have "Axel" as "function_of" and "Axel_Blog" as
> "has_scope".
>
> Finally, these relations are represented without using a bnode.
>
> Hoping this helps,
>
> Andrés

Yes, andrés, that was my point: If this is what you suggest as a
solution (roles are forum specific) then you need to declare the
property "scope_of" functional in the OWL ontology, in order to disallow
that the same role is used in several forums. Otherwise, you loose the
distiction of who plays which role in which forum. Or, if you reuse the
same role in several forums, it means that each user who plays a certain
role, plays it in all forums which declare this role.

cheers,
axel

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, September 14 - 16:39 — andresmo

comments on the current submission document...

Hi Axel,

>
> Yes, andrés, that was my point: If this is what you suggest as a
> solution (roles are forum specific) then you need to declare the
> property "scope_of" functional in the OWL ontology, in order to disallow
> that the same role is used in several forums. Otherwise, you loose the
> distiction of who plays which role in which forum. Or, if you reuse the
> same role in several forums, it means that each user who plays a certain
> role, plays it in all forums which declare this role.
>

Well, in fact I think that roles are not only forum specific, but also
could be used in Site, Community, etc, those that I call
"Managed_Element". Moreover, I think that there is no problem in using
the same role in different forums.

For example, and going on with the previous example, suppose that we
have a new Forum instance, "BulletinSportNews". Now imagine that I want
to be administrator of that forum, so I create the instance "Admin3"
that have "Andres" as "function_of" property value and
"BulletinSportNews" as "has_scope" value.

As a result, now I'm using the same role (Administrator) in several
Forums ("The Beatles Forum" and "BulletinSportNews"), but I'm not
administrator of the "Alex_Blog" forum, although this forum declares
that it has an administrator (who is "Alex").

What do you think about it?

Regards,
Andrés

2006, September 14 - 16:39 — Axel Polleres

comments on the current submission document...

andresmo wrote:
> Hi Axel,
>
>
>>Yes, andrés, that was my point: If this is what you suggest as a
>>solution (roles are forum specific) then you need to declare the
>>property "scope_of" functional in the OWL ontology, in order to disallow
>>that the same role is used in several forums. Otherwise, you loose the
>>distiction of who plays which role in which forum. Or, if you reuse the
>>same role in several forums, it means that each user who plays a certain
>>role, plays it in all forums which declare this role.
>
> Well, in fact I think that roles are not only forum specific, but also
> could be used in Site, Community, etc, those that I call
> "Managed_Element". Moreover, I think that there is no problem in using
> the same role in different forums.
>
> For example, and going on with the previous example, suppose that we
> have a new Forum instance, "BulletinSportNews". Now imagine that I want
> to be administrator of that forum, so I create the instance "Admin3"
> that have "Andres" as "function_of" property value and
> "BulletinSportNews" as "has_scope" value.

ok, so you say that the class "Administrator" is a subclass of
sioc:role? And the role played by a certain person in a particular forum
("Admin3") is an instance of this class, correct?

Looks ok (hmmm, it mixes a bit what is a class and what is an instance,
doesn't it? One would naturally expect that "Administrator" is an
instance of the class "Role", or no? But well.), Hovever...

...what I meant to ask is: what prevents me to say:

Admin3 sioc:has_scope BulletinSportNews
Admin3 sioc:has_scope Alex_Blog

Do you want to allow a particular role *instance* to span several forums?

> As a result, now I'm using the same role (Administrator) in several
> Forums ("The Beatles Forum" and "BulletinSportNews"),

you are using the same *subclass* but not the same *instance*.
Correct?

cheers,
axel

--
Dr. Axel Polleres
email: axel@polleres.net url: http://www.polleres.net/

2006, September 14 - 16:39 — andresmo

comments on the current submission document...

Hi Alex!! Nice to discuss with you these issues!!

> > For example, and going on with the previous example, suppose that we
> > have a new Forum instance, "BulletinSportNews". Now imagine that I want
> > to be administrator of that forum, so I create the instance "Admin3"
> > that have "Andres" as "function_of" property value and
> > "BulletinSportNews" as "has_scope" value.
>
> ok, so you say that the class "Administrator" is a subclass of
> sioc:role? And the role played by a certain person in a particular forum
> ("Admin3") is an instance of this class, correct?

Right, it's like that.

> Looks ok (hmmm, it mixes a bit what is a class and what is an instance,
> doesn't it? One would naturally expect that "Administrator" is an
> instance of the class "Role", or no? But well.), Hovever...

Well, suppose that together with "Administrator", you want to express
other specific roles as "Moderator", "Registered_User", "Banned_User",
etc. Perhaps it is better designed using subclasses, each one with its
own properties.

By the way, I think that the "Role" concept is necessary in the SIOC
ontology's core, but as you've pointed, a module containing these
specific roles modelled as subclasses
could be also a good idea.

> ...what I meant to ask is: what prevents me to say:
>
> Admin3 sioc:has_scope BulletinSportNews
> Admin3 sioc:has_scope Alex_Blog
>
> Do you want to allow a particular role *instance* to span several forums?

Ok, now I've got your point. Well, it could be a ontology designer's
choice to allow spanning several forums, I mean, it is possible that
the same user with a given role could manage several forums. I think
we need to discuss this issue.

>
> > As a result, now I'm using the same role (Administrator) in several
> > Forums ("The Beatles Forum" and "BulletinSportNews"),
>
> you are using the same *subclass* but not the same *instance*.
> Correct?
>

Yes, but as you've pointed above, you can use the same instance also,
if the ontology's design allows it.

Regards,
Andrés

2006, September 14 - 16:39 — Cloud

comments on the current submission document...

Hi all -

I think it still works, even if you need to go and find who the
moderators are for a particular forum. It depends on how your forum is
set up - i.e. can all moderators moderate all forums (1) or do they have
a specific role for a specific forum (2)?

(1)

Instance John (type User) -> has_function -> Instance Moderator (type
Role) -> has_scope -> TV (type Forum)
Instance Mary (type User) -> has_function -> Instance Moderator (type
Role) -> has_scope -> Radio (type Forum)
Instance Jane (type User) -> has_function -> Instance Moderator (type
Role) -> has_scope -> Radio (type Forum)

(2)

Instance John (type User) -> has_function -> Instance TVModerator (type
Role) -> has_scope -> TV (type Forum)
Instance Mary (type User) -> has_function -> Instance RadioModerator
(type Role) -> has_scope -> Radio (type Forum)
Instance Jane (type User) -> has_function -> Instance RadioModerator
(type Role) -> has_scope -> Radio (type Forum)

In case (2), you can still find out who moderates the Radio forum.

J.
--

2006, September 14 - 16:39 — Jack Park

comments on the current submission document...

Lots of really thoughtful comments in this thread. Let me toss in my take on it, one that, I think, amplifies some earlier statements, and possibly contradicts others.

My view is that roles are core to any social modeling exercise. They can, indeed, be extensible, but there should be an "upper" notion of roles. The mathematician Stan Ulam was once asked (by Giancarlo Rotta) what he thought about ai (artificial intelligence). Ulam's response, highly condensed, was that ai would arrive when it found a way to model the notion of "as", as in, seeing as, cast in the role as, etc. Roles, it would seem, are important. Ulam's example: when you watch two people drive by in a car, you see one person as the driver and one person as the passenger. Seems you need to model that as a central capability.

So, having Administrator as a subclass of sioc:Role makes plenty of sense. sioc:Role seems core, Administrator is just one way to model folks who do administrative things. The trick, it seems to me, will be to have the ability to capture all the many ways to model the administrator role, and to recognize when those different models are actually the same thing. I say that because, in the end, it strikes me that SIOC will want to be able to "learn" new information by merging with heterogeneous resources that are not SIOC bound.

Back to modeling roles.
Admin3 is properly an instance of Administrator. There is no mixing going on here. To see what I mean, consider this example.

Joe is the administrator of the XYZ forum.
That's a statement of fact. (fictional, of course)

To model it, I need to create an instance of a role, and, thinking about things in a broader sense than SIOC presently appear to do (unless I missed something), I need to model the role of the forum (administratedForum) and I need to model the relationship made here, the administrator-forum relationship. I could create that as a class, subclass of, say (making this up now) sioc:Relationship. Then instantiate it with identifiers that say, in essence, joe-administrator-forum-xyz.

Thus, there would, in this particular world view, be a model that looks something like this:

                   joe-administrator-role                                  xyz-administratedForum-role

                              |                                                                     |
Joe------------------------ --------joe-administrator-forum-xyz--------------------- --------------XYZ

A reason for doing this (your mileage may vary) is that you might want to be able to model things about the relationship itself, like, when the relationship started, ended, etc. You might want to say, e.g.
Joe became administrator of XYZ forum on xxx date.

or
The XYZ forum is now co-administrated by Sue.
That statement affects the original assertion in a temporal sense, among other things.
A side benefit is that you now provide more dimensions along which people can perform searches and inferences on an SIOC-based knowledge base. When you look at "delicious" (social bookmarking site
http://del.icio.us/ ), there are three dimensions around which you can "pivot", the pivot point being a "bookmark" -- those dimensions are user, tag, and bookmarked resource. By modeling SIOC relationships in the broader sense I am suggesting here, you provide more ways to "pivot" around central ideas. More concepts become pivot centers.

Point of fact, this is the topic maps perspective on what you are trying to model. A fair question is: does it add value to SIOC? Answers to that question will derive from the statements you make regarding the full Monty goals of SIOC itself.

Just a few centavos.
Cheers
Jack

On 9/14/06, John Breslin <john.breslin@deri.org> wrote:

Hi all -

I think it still works, even if you need to go and find who the

moderators are for a particular forum. It depends on how your forum is
set up - i.e. can all moderators moderate all forums (1) or do they have
a specific role for a specific forum (2)?

(1)

Instance John (type User) -> has_function -> Instance Moderator (type

Role) -> has_scope -> TV (type Forum)
Instance Mary (type User) -> has_function -> Instance Moderator (type
Role) -> has_scope -> Radio (type Forum)
Instance Jane (type User) -> has_function -> Instance Moderator (type

Role) -> has_scope -> Radio (type Forum)

(2)

Instance John (type User) -> has_function -> Instance TVModerator (type
Role) -> has_scope -> TV (type Forum)
Instance Mary (type User) -> has_function -> Instance RadioModerator

(type Role) -> has_scope -> Radio (type Forum)
Instance Jane (type User) -> has_function -> Instance RadioModerator
(type Role) -> has_scope -> Radio (type Forum)

In case (2), you can still find out who moderates the Radio forum.

J.
--

--~--~---------~--~----~------------~-------~--~----~

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

2006, September 15 - 08:55 — andresmo

comments on the current submission document...

Hi all, we are building a very interesting thread!!!

These are my comments about Jack's ideas...

> So, having Administrator as a subclass of sioc:Role makes plenty of sense.
> sioc:Role seems core, Administrator is just one way to model folks who do
> administrative things. The trick, it seems to me, will be to have the
> ability to capture all the many ways to model the administrator role, and to
> recognize when those different models are actually the same thing. I say
> that because, in the end, it strikes me that SIOC will want to be able to
> "learn" new information by merging with heterogeneous resources that are not
> SIOC bound.

Totally agree

>
> Back to modeling roles.
> Admin3 is properly an instance of Administrator. There is no mixing going on
> here. To see what I mean, consider this example.
>
> Joe is the administrator of the XYZ forum.
> That's a statement of fact. (fictional, of course)
>
> To model it, I need to create an instance of a role, and, thinking about
> things in a broader sense than SIOC presently appear to do (unless I missed
> something), I need to model the role of the forum (administratedForum) and I
> need to model the relationship made here, the administrator-forum
> relationship. I could create that as a class, subclass of, say (making this
> up now) sioc:Relationship. Then instantiate it with identifiers that say, in
> essence, joe-administrator-forum-xyz.
>
> Thus, there would, in this particular world view, be a model that looks
> something like this:
>
> joe-administrator-role
> xyz-administratedForum-role
>
> | |
> Joe------------------------
> --------joe-administrator-forum-xyz--------------------- --------------XYZ
>

So, if I've understood correctly your example, we've got the following
model:

- Joe, instance of sioc:User
- XYZ forum, instance of sioc:Forum
- Joe-admin-role, instance of sioc:Administrator (subclass of
sioc:Role)
- XYZ-administratedForum-role ????? , instance of sioc:Role, trying to
model the role of a forum????
- Joe-administrator-forum-XYZ, instance of sioc:Relationship (or some
subclassess of this)

Then, the relations among these instances would be something like

Joe ---> (hasRelation, a new property) -->
Joe-administrator-forum-XYZ --> (relatedTo, new property) --> XYZ_Forum

But, what is the 'role' of the "role instances" (sorry for that) used
for? I mean, I can't see how do you add the role instances in these
relations.

I consider that "Relationship" concept is a good idea, but I would
model it like this:

Class --> sioc:Relationship

Properties--> -sioc:owner, range: User, Usergroup (Person or group
from whom the relation starts, flows towards another object)

-sioc:mode, range: Role (Type of relation)

-sioc:target, range: Forum, Site, etc (Object that is 'owned' or
'controlled' in the relation)

-... Other properties, as started_at, ended_at, notes, etc

So, the previous example would be something like (keeping the same
names)

Joe-->(sioc:owner)-->Joe-administror-forum-XYZ-->(sioc:target)-->XYZForum
^
|
|
(sioc:mode)
^
|
|
Joe-admin-Role

But, as Jake says, I also have doubts about if it is necessary or it is
what we really are looking for...

Hoping to hear from you soon,

best regards,
Andrés

2006, October 6 - 10:35 — Jack Park

comments on the current submission document...

Andrés

Your last sentence says it all: " also have doubts about if it is necessary or it is
what we really are looking for..."
Recall that my last sentence "Answers to that question will derive from the statements you make regarding the full Monty goals of SIOC itself.
" allowed as to how the goals of SIOC may not call for the level of detail in domain modeling that I suggest.

Indeed, I've been looking around, albeit a bit fragmented, for some statements that clearly articulate those requirements for SIOC that would allow me to understand to what granularity SIOC models should satisfy. Perhaps I missed those, or misinterpreted what I have seen thus far. It's up to the SIOC tribe to decide, not me.

An idea central to the semantic web is answering questions. Some questions will require inferencing, others can be satisfied by simple keyword search. Sometimes, inferencing requires looking up the the semantic closure of some class or instance to find an answer, other times, you just query the object that represents the class or instance.

But, which object is it that represents *the* class or instance about which you seek answers? Suppose, for instance, you ask "did Jack Park author a book on baseball?" The correct answer for this Jack Park (moi) is "nope." In fact, you need to disambiguate the name Jack Park from more than a dozen of them that pop up in google. The guy who wrote the baseball book lives in Ohio. This Jack Park wrote a book about wind energy, and edited and coauthored one about XML Topic Maps. I am making the case that name-based modeling is problematic. I am also making the case that, sometimes, to disambiguate subject references, you need a rather finely-grained model.

It's the SIOC tribe's choice what questions it chooses to answer with what level of precision and reliability. What I sketched is a rather finer-grained approach than that taken with SKOS. I am, in no way, suggesting that SKOS is inadequate. Indeed, it represents a kind of simplification over XTM. I don't model to either these days; rather, I believe that the topic maps reference model (TMRM) gives me a greater degree of liberty to model the way I see fit and still satisfy the major premises of topic mapping. Is SIOC about topic mapping? Is the semantic web about topic mapping? That's a rather presumptuous question, but in the large, in theory, all knowledge modeling is about answering questions.

It's your call.
Cheers
Jack

On 9/15/06, andresmo <amunoz@um.es> wrote:

Hi all, we are building a very interesting thread!!!

These are my comments about Jack's ideas...

> So, having Administrator as a subclass of sioc:Role makes plenty of sense.
> sioc:Role seems core, Administrator is just one way to model folks who do

> administrative things. The trick, it seems to me, will be to have the
> ability to capture all the many ways to model the administrator role, and to
> recognize when those different models are actually the same thing. I say

> that because, in the end, it strikes me that SIOC will want to be able to
> "learn" new information by merging with heterogeneous resources that are not
> SIOC bound.

Totally agree

>
> Back to modeling roles.
> Admin3 is properly an instance of Administrator. There is no mixing going on
> here. To see what I mean, consider this example.
>
> Joe is the administrator of the XYZ forum.

> That's a statement of fact. (fictional, of course)
>
> To model it, I need to create an instance of a role, and, thinking about
> things in a broader sense than SIOC presently appear to do (unless I missed

> something), I need to model the role of the forum (administratedForum) and I
> need to model the relationship made here, the administrator-forum
> relationship. I could create that as a class, subclass of, say (making this

> up now) sioc:Relationship. Then instantiate it with identifiers that say, in
> essence, joe-administrator-forum-xyz.
>
> Thus, there would, in this particular world view, be a model that looks

> something like this:
>
>                    joe-administrator-role
> xyz-administratedForum-role
>
> |                                                                     |
> Joe------------------------

> --------joe-administrator-forum-xyz---------------------  --------------XYZ
>

So, if I've understood correctly your example, we've got the following
model:

- Joe, instance of sioc:User

- XYZ forum, instance of sioc:Forum
- Joe-admin-role, instance of sioc:Administrator (subclass of
sioc:Role)
- XYZ-administratedForum-role ????? , instance of sioc:Role, trying to
model the role of a forum????

- Joe-administrator-forum-XYZ, instance of sioc:Relationship (or some
subclassess of this)

Then, the relations among these instances would be something like

  Joe ---> (hasRelation, a new property) -->

Joe-administrator-forum-XYZ --> (relatedTo, new property) --> XYZ_Forum

But, what is the 'role' of the "role instances" (sorry for that) used
for? I mean, I can't see how do you add the role instances in these

relations.

I consider that "Relationship" concept is a good idea, but I would
model it like this:

Class --> sioc:Relationship

   Properties--> -sioc:owner, range: User, Usergroup  (Person or group

from whom the relation starts, flows towards another object)

       -sioc:mode, range: Role (Type of relation)

       -sioc:target, range: Forum, Site, etc (Object that is 'owned' or
'controlled' in the relation)

        -... Other properties, as started_at, ended_at, notes, etc

So, the previous example would be something like (keeping the same
names)

Joe-->(sioc:owner)-->Joe-administror-forum-XYZ-->(sioc:target)-->XYZForum

                                      ^
                                      |
                                      |
                               (sioc:mode)
                                      ^

                                      |
                                      |
                              Joe-admin-Role

But, as Jake says, I also have doubts about if it is necessary or it is

what we really are looking for...

Hoping to hear from you soon,

best regards,
Andrés

--~--~---------~--~----~------------~-------~--~----~

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

2006, September 12 - 09:00 — Cloud

Contribution from UMU to SIOC Ontology

Dear Andres -

These are very valuable comments, and I think we will have to revise the
Role concept as a result and also think about your Topic idea.

andresmo wrote:
> ·Forum
> - It is declared that a forum will have a moderator or
> administrator, but how is this relation represented in the model? Does
> it come implicitly by a concrete role played by a subscriber of the
> forum?

Will talk about this under User.

> - The meaning of "scope_of" property is not quite clear.
> Does it mean that a forum is only visible to a fixed type of role? Or
> is it interesting to a specific type of role?

The latter, so if the Role links a User to a Forum, and the Role is of
type Moderator let's say, then this would be:

User -> has_function -> Role (of whatever type, e.g. Moderator) ->
has_scope -> Forum

Think of has_scope as where the Role applies to...

> Another possibility that we have thought of is that this property tries
> to represent the administration relation that we have mentioned in the
> previous point, but it seems a bit weird, because is a user who
> moderates a Forum, not a role.

This is true, but having multiple Roles means that a user can have
different Roles for different objects, and these Roles can be futher
refined (e.g. I may be able to moderate forums A and B, but on forum B I
can also see a user's IP address whereas on A i cannot).

> - A forum could be devoted to a certain group of users, but
> how is represented the relation among forums and groups of users, that
> is to say, how do you associate a group of user with a forum? It seems
> that neither a direct relation nor an indirect one model this fact.

Good idea. This could be addressed by opening up the Role to Usergroups
as well as Users. e.g.

Forum -> scope_of -> Role (Private Member) -> function_of -> Usergroup
or Set of Users

> ·Post
> - "Content" and "description" properties have got the same
> semantic meaning; it seems that there is no difference between them. We
> have read in [1] that currently it is being considered the idea of
> inserting AtomOWL to represent the content of a post, which sounds to
> be a good choice. So we suppose that these two properties will be
> reduced to one of this AtomOWL type.

Actually, description is like an abstract, whereas content is the full
posted message. We propose to continue to use description for the short
version, content for the long version, content:encoded from Atom for the
encoded long version.

> ·User
> - As in Forum class, we can't see a relation that allows
> representing that a user is moderator of a forum or site, as is stated
> in the specification. That is to say, we miss a property that relates a
> user with the administrator role with a forum, and its inverse (a forum
> that is administrated by a user), like "subscriber_of" property does.

What you would do is say that User -> has_function -> Role (of subtype
Administrator or Moderator) -> has_scope -> Forum. The inverse is then
Forum -> scope_of -> Role (of subtype whatever) -> function_of -> User.

Since we added a has_subscriber shortcut for User -> has_fn -> Role
(Subscriber) -> has_scope -> Forum, similarly, I think we could add a
has_moderator or has_administrator shortcut...

But at the moment, the range of Role means that this can't be applied to
Site, when maybe it should (or even to Community).

> ·Usergroup
> - Should "usergroups" have a role?

Yes, and this was the intent at the beginning but having multiple
domains for a concept seems to be a problem. We could probably just
open up the domain and range of Role to solve this.

> ·About "topic" property
> We think that "topic" property should be modelled as a class
> and not as a property, since topic is a sufficiently important entity
> to having its own properties: category, description, keywords, impact
> factor, etc.

I think that SKOS sufficiently describes this class, see skos:Concept
[1]. But if you think not, let us know!

[1] http://www.w3.org/2004/02/skos/core/spec/#Concept

Again, many thanks!

To summarise, the above issues could be solved by:

1. Removing the domain / range constraints on Role (at the moment the
domain is User and the range is Forum). This would allow the range to
be User, Usergroup and the range to be Forum, Site, Community etc.)

2. Adding has_moderator and has_administrator properties to Forums and
Sites respectively.

Please let us know your opinions on 1 and 2.

John.
--

Contribution from UMU to SIOC Ontology

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

comments on the current submission document...

Contribution from UMU to SIOC Ontology

Primary links

Syndicate

User login