SIOC Ontology Issues

This page contains issues related to to the SIOC Ontology. Including proposed additions / deletions / updates to the ontology.

Identifying Individual Users

Issue:

There is a need to identify individuals, to link together their submissions from different community sites.

Other IFPs in FOAF: aimChatID, homepage, icqChatID, jabberID, msnChatID, weblog, yahooChatID. We can also add skypeChatID (but we would have to continue a list and keep adding new IDs when new services appear).

Currently we lack a suitable method to identify a person, and consequently link to them. Can add mbox and mbox_sha1sum as IFP (inverse functional properties) for sioc:User. These would nicely map to those for foaf:Person. We need the sha1sum to hide the personal information. (Andreas Harth mentioned there are other ways to link to resources / individuals apart from IFPs and that Knud Moeller has done some work related to this.)

Solution:

Done.

Divide a User's sioc:name into Two Parts

Issue:

This is to reflect the fact that many systems keep first names and surnames separate, and therefore SIOC should also have separate properties. It is easier to join them when displaying instead of extracting parts from a sioc:name property.

Looking at NamesInFoaf, there is no agreement on this and actually the simplest proposal is to keep name property and add more elaborate way to describe sequence of names.

Proposal: keep sioc:name and introduce two new properties, for first name / last name OR for given name / surname. Which of those two to choose?! The first seems a good choice.

Solution:

Done.

Groups of Individuals vs. Types of Individuals

Issue:

Should we represent special groups of authors as:

1. Separate instances of sioc:Administrator (subclass of sioc:User) without further grouping, or
2. Special subclasses of sioc:Group like sioc:Administrators?

The latter would allow us to list all the administrators and we can keep the existing subclasses of sioc:User and be able to infer (?x :member_of :Administrators) => (?x rdf:type sioc:Administrator).

Proposed additions: For each subclass of sioc:User add a relevant subclass of sioc:Group.

Solution:

Use sioc:Role instead.

Roles of Some Subclasses of sioc:Person

Issue:

At least one of the subclasses of sioc:Person, sioc:Moderator has badly-defined semantics.

For example, if we know they are a sioc:Moderator, what do we know about them. We may deduce that there exists a forum :f for which this person :x is a moderator. But that is not a site-wide status: they might be a moderator on one forum, but just a regular user on an other.

Proposal: clarify this issue.

Solution:

Added sioc:Role.

Name of Property sioc:created is Ambiguous

Issue:

This property says "When this was created, in ISO 8601 format". Yet, the property name does not indicate that it is a date/time.

Proposal: Change the name to 'date_created' or similar.

Solution:

Changed to created_at.

WordPress SIOC Export

This is the summary of assumptions used in creating a WP SIOC export.

User Information

1. Each sioc:User gets an rdf:nodeID="u-3" assigned to it, where 3 is the user id in the system.
2. sioc:name contains a user's prefered displayed name as determined by their blog settings.
3. sioc:description = sioc:firstName . ' ' . sioc:surname.
4. Properties sioc:firstName and sioc:surname are introduced (now first_name, last_name).
5. Properties sioc:mbox and sioc:mbox_sha1sum are introduced (now email, email_sha1).

Forum Information

1. A blog has one sioc:Forum with rdf:nodeID="f-1".
2. Forum has a sioc:name = "Main blog at $weblog_name".
3. Do we need to add a property for forum (site) url? (now can use sioc:link).
4. Also, do we need to point to RSS feeds if we export the same information in SIOC?  What about the applications that do not grok SIOC?

Post Information

1. Property sioc:created is named ambiguously.
2. We need a property to indicate post title: proposals are 'title' or 'name'.
3. Also might need properties for the URL and the RSS feed.
4. Assuming that we indicate sioc:has_creator property with rdf:nameID="u-3" (where 3 is the user's ID), do we also link a post to its creator via sioc:mbox or mbox_sha1sum properties?  If so, then how do these co-exist?
5. RSS 1.0 has the property "description" for a plain text contents (possibly abbreviated) and content:encoded for full (HTML / CDATA) content.  SIOC currently has only sioc:content.  Need decision about what type of content we put in sioc:content and if we need two separate properties: one for plain-text and the other for rich-text.

Groups and sioc:knows Relation

Issue:

John asks should we have sioc:knows relation for Groups (similar to foaf:knows for Person).

So, what is the purpose of sioc:knows between sioc:Groups?

Solution:

None yet.

New / Missing Properties

* The paper describes sioc:closed property, but should it be closed_at in the ontology?
* sioc:knows is in the paper, but not in the ontology.
* Event was changed from a class to a property of Post.  Also added start and end dates.
* The event propery name does not clearly define what is a sioc:event of sioc:Post.
* From modelling point of view, event is best displayed as a subclass of sioc:Post, possibly in a separate "types" module.
* Solution: remove event, starts_at, finishes_at and go through it again.

Cardinality of properties

A few reflexions regarding cardinality of properties, based on v1.09 of the ontology (deprecated properties are not mentionned). Using min / max for owl:mincardinality and owl:maxcardinality restrictions. If nothing is mentionned, there is no restrictions (just let there for maintenance, if some want to add restrictions). Adding cardinality to properties will imply to change these properties from rdfs:property to owl:objectProperty / owl:datatypeProperty.

account_of: min = 1; max = 1 . If an account is shared by more that one foaf:Person, then use a foaf:Group as sioc:account_of has foaf:Agent for range

attachment

avatar: max = 1 ? A foaf:Person can have many foaf:depiction, but for a give user maybe one avatar is enough ?

container_of

content: min = max = 1. Only one content for a post (+ the encoded version)

creator_of

email: max=1 ? (only on email per sioc:User ?) needed ?

email_sha1: same as email

function_of

group_of

has_container: min = 1; (if max = 1, we can use sioc:sibling)

has_creator: no min, as we can have only foaf:maker; no max (i.e. colaborative pages / wikis)

has_function

has_group

has_host: min = 1; max ?

has_member

has_parent

has_part

has_reply

has_modifier

has_scope

has_subscriber

host_of

id: max = 1

ip_adress: max = 1

link: max = 1 (?)

links_to

member_of

name: min = 1 (needed ?); max = 1 (only on name per sioc:User ?)

next_version

note

parent_of

part_of

previous_version

related_to

reply_of

modifier_of

scope_of

sibling

subscriber_of

topic

views