Revisions to the SIOC Ontology
Uldis Bojars
Below is information about proposed changes to the SIOC ontology. John
Breslin and me have made a summary of them which I am posting here to
collect your feedback.
General info about SIOC: http://rdfs.org/sioc/
The actual changes to RDFS/OWL "code" can be seen as the difference
between current ontology [1] and the version with proposed changes
implemented [2]. A part of these changes have been discussed on
SIOC-Dev and RDF-Web mailing lists before.
In particular we will be grateful if those of you who have experience
in designing and improving the FOAF ontology would help improve SIOC.
[1] http://rdfs.org/sioc/ns
[2] http://sw.deri.org/svn/sw/2005/08/sioc/ns/sioc
A detailed list of changes:
http://sw.deri.org/svn/sw/2005/08/sioc/ns/CHANGES
=1= Use foaf:Person instead of sioc:User for person's data
Name, surname and other personal data will be described via a
foaf:Person, which will point to the sioc:User (person's account on the
community site) using foaf:holdsAccount property.
Actions:
- deprecate sioc:first_name and sioc:last_name
Open questions:
- how to keep the information that this _particular_ account is
associated with a given e-mail address (or hash of it)? we might also
deprecate foaf:email and foaf:email_sha1 and use FOAF properties, but
shall we not worry that when person's data are smushed together we
loose a link between OnlineAccount and an e-mail address?
- same can be true of name (e.g., if the person has a different name
specified for each site)
=2= Changes to properties representing plain/rich content
sioc:content is redundant - SIOC has sioc:description (subclass of
dc:description) using which is more consistent.
sioc:content_encoded - there is already content:encoded module for RSS
1.0 that can be used to describe encoded content (e.g., HTML). let's
leave it out of SIOC ontology for now as encoding and describing rich
content can be a complex task.
Actions:
- deprecate sioc:content (use sioc:description instead) and
sioc:content_encoded (use content:encoded instead)
- change rdfs:comment for sioc:description accordingly (TODO)
=3= Cleanup
Remove:
- commented out events related properties (starts_at, finished_at,
event) - events are outside scope
- sioc:is_category and sioc:is_closed
- sioc:location
Change property name / fix description:
- sioc:has_revisor to :has_modifier (modification better describes
changing the Post)
- sioc:reference to :links_to (reference has vague meaning, also does
not fit out naming convention)
- sioc:revisor_of to :modifier_of
Change range:
- sioc:type - range to rdfs:Resource
=4= Change roles / permissions properties
Change description and domain/range:
- sioc:function_of - range to sioc:user (removes Usergroup from its
range)
- sioc:has_scope - range to sioc:Forum
- sioc:scope_of - range to Resource
=5= Changes to subject, topic, title
Separate subject information into:
- text (e.g., keywords) described by sioc:subject
- resources (e.g., SKOS concepts) described by sioc:topic
Actions:
- change description of sioc:subject + remove domain of sioc:Post +
subclass from dc:subject
- change description of sioc:topic + change range to rdfs:Resource
- add sioc:title property (take former description of sioc:subject) +
subclass from dc:title
=6= Names, IDs
add sioc:id - a new property to represent the ID of the SIOC object
(e.g., user ID, post ID, ...)
change description of sioc:name to use it to represent user / account
names for sioc:User(s) and sioc:Usergroup(s)
=Open Questions=
-?- Shall we subclass sioc:created_at and sioc:modified_at from dc:date
or dc_terms:issued and dc_terms:modified ?
-?- Shall we subclass sioc:link (used to describe link to a web page
about the SIOC object - Post, User, ...) from dc:identifier ?
-?- Shall we change the way we represent modifications / different
versions of the data? Currently we have rather simple next_version,
previous_version and has_modifier, modifier_of. Another option is to
introduce "modification events" that we can add more information to [at
a cost of the complexity of data/ontology]
CHANGES file has slightly more details, though I've covered 95% of them
in this post.
Note to developers: some of the proposed changes will have impact on
the SIOC export tools. Please come to the SIOC-Dev mailing list,
discuss and ask for more information if needed.
Best regards,
Uldis
[ http://captsolo.net/info/ ]
[ CaptSolo @ #foaf and #swig ]
Alexandre Passant
A bit late, but here are a few remarks about the proposed changes:
=1= Use foaf:Person instead of sioc:User for person's data
Name, surname and other personal data will be described via a
foaf:Person, which will point to the sioc:User (person's account on the
community site) using foaf:holdsAccount property.
I also think this is the best way to do mapping between FOAF and SIOC.
(detail: as sioc:User will be a foaf:OnlineAccount, maybe naming it sioc:Account/UserAccount would be better than sioc:User)
There's also might be a sioc:owned_by property to make a sioc:User/Account point to a foaf:Person (as it doesn't seem there's an inverse of foaf:holdsAccount yet).
Then, there could be a sioc:accountName, to define the Account name / login, which might be a subclass/sameAs of foaf:accountName.
=3= Cleanup
Remove:
- commented out events related properties (starts_at, finished_at,
event) - events are outside scope
- sioc:is_category and sioc:is_closed
- sioc:location
Regarding the location of the user, I think it's better to let FOAF manage it, eg using Geo vocabulary [1]. And maybe keep sioc:location for the location of a post ?
=5= Changes to subject, topic, title
Separate subject information into:
- text (e.g., keywords) described by sioc:subject
- resources (e.g., SKOS concepts) described by sioc:topic
Good idea to separate both.
=Open Questions=
-?- Shall we change the way we represent modifications / different
versions of the data? Currently we have rather simple next_version,
previous_version and has_modifier, modifier_of. Another option is to
introduce "modification events" that we can add more information to [at
a cost of the complexity of data/ontology]
If previous / next are transitive properties, and using created_at and has_creator /has_modifier for each versionned Post, I think we can get all relevant information about versions of the data.
Yet, a version_comment attribute could be added to sioc:Post, so that each post may have a short description about its revision (eg: "initial version", "typo..." as we can do in some wikis, or in CVS).
Uldis Bojars
Thanks for your comments. :)
On 5/22/06, Alexandre Passant <al...@passant.org> wrote:
> > =1= Use foaf:Person instead of sioc:User for person's data
> Then, there could be a sioc:accountName, to define the Account name /
> login, which might be a subclass/sameAs of foaf:accountName.
A good suggestion. sioc:name was meant for this purpose (according to
changes in new ontology version when it is no longer needed for
expressing short name of something), but we did not think of
accountName property that is inherited from FOAF.
Do others have suggestions which to use - sioc:name or foaf:accountName?
Note: sioc:name is meant to be used for both sioc:User and Usergroup.
Although I can not remember right now what is the rationale for
account names in case of Usergroup. Maybe John knows more about this.
> > =5= Changes to subject, topic, title
> > Separate subject information into:
> > - text (e.g., keywords) described by sioc:subject
> > - resources (e.g., SKOS concepts) described by sioc:topic
>
> Good idea to separate both.
I found some notes from our meeting with DanBri, Libby and Alistair on
describing topics of Posts (see the figure below). There you can see
different ways of describing topics. May be useful for integrating
SKOS.
http://rdfs.org/2005/11/sioc-topic.jpg
> > =Open Questions=
>
> If previous / next are transitive properties, and using created_at and
> has_creator /has_modifier for each versionned Post, I think we can get all
> relevant information about versions of the data.
> Yet, a version_comment attribute could be added to sioc:Post, so that each
> post may have a short description about its revision (eg: "initial version",
> "typo..." as we can do in some wikis, or in CVS).
We can use previous / next properties for now. Shall we make them
transitive then? And what questions does that help us to answer from
the data?
We will need to develop this the future - when looking at a use case
where versions are more important than in a blog or forum posts (e.g.,
wikis).
Here's a wiki page for discussion, please add your comments:
http://esw.w3.org/topic/SIOC/VersionTracking
Uldis
Fred
Hi,
Then, there could be a sioc:accountName, to define the Account name / login, which might be a subclass/sameAs of foaf:accountName.
I had the same question, but in the mean time, I would (and will: for a project I am working on right now, more information in this later) use a "rdfs:seeAlso" property to create the bridge between a sioc:User and it's personal profile (foaf:Person).
I don't know if it is better then incorporating a new sioc property but considering that it is a common practice to refer a "foaf:knows" property to the "knows"'s Foaf profile, it could do the job for the moment I think. Are my assumptions good?
There is what I mean:
____
dbrickley
Dan Brickley
____
____
Thanks,
Salutations,
Fred
Richard Cyganiak
browse_thread/thread/b8e3f8ceb73b29f5
> =1= Use foaf:Person instead of sioc:User for person's data
>
> Name, surname and other personal data will be described via a
> foaf:Person, which will point to the sioc:User (person's account on
> the
> community site) using foaf:holdsAccount property.
If I understand correctly, you propose this:
<#richard> a foaf:Person .
<#richard> foaf:holdsAccount <#richardInForum> .
<#richardInForum> a sioc:User .
That's not good, because <#richardInForum> would be both a
foaf:OnlineAccount and a sioc:User, which seems wrong to me. Rename
sioc:User to sioc:UserAccount?
How would you model the association between an author and her posts?
<#richard> sioc:creator_of <#post123> .
or
<#richardInForum> sioc:creator_of <#post123> .
?
I think the first one is better, the association should be between
the *person* and the post, not the *account* and the post. That's how
dc:creator and foaf:maker work. Of course then you couldn't record
any more that a single person posts from multiple accounts. From my
point of view that would be acceptable.
> Actions:
> - deprecate sioc:first_name and sioc:last_name
+1
> Open questions:
> - how to keep the information that this _particular_ account is
> associated with a given e-mail address (or hash of it)? we might also
> deprecate foaf:email and foaf:email_sha1 and use FOAF properties, but
> shall we not worry that when person's data are smushed together we
> loose a link between OnlineAccount and an e-mail address?
I wouldn't worry about that. When you smush, you always lose some
information. If someone cares about the association, then they
shouldn't smush, or keep the original data around to check which
source the triple is from.
> - same can be true of name (e.g., if the person has a different name
> specified for each site)
Ditto, don't worry too much.
> =2= Changes to properties representing plain/rich content
>
> sioc:content is redundant - SIOC has sioc:description (subclass of
> dc:description) using which is more consistent.
Is sioc:content really the same as sioc:description? FWIW,
dc:description is defined as "An account of the content of the resource.
Description may include but is not limited to: an abstract, table of
contents, reference to a graphical representation of content or a
free-text account of the content." I read this as some kind of
summary of the content.
> sioc:content_encoded - there is already content:encoded module for RSS
> 1.0 that can be used to describe encoded content (e.g., HTML). let's
> leave it out of SIOC ontology for now as encoding and describing rich
> content can be a complex task.
+1
(snip)
> Change range:
> - sioc:type - range to rdfs:Resource
There is rdf:type already, the most universal property in all of RDF.
Please drop sioc:type, it makes you look silly.
(snip)
> =5= Changes to subject, topic, title
> Separate subject information into:
> - text (e.g., keywords) described by sioc:subject
Please make it a subclass of rdfs:label.
> - resources (e.g., SKOS concepts) described by sioc:topic
sioc:topic is pretty useless unless there's a method of actually
defining the topics/categories/concepts. I'd say drop it. Any
external vocabulary for describing topics, e.g. SKOS, already comes
with an equivalent of sioc:topic.
(snip)
> -?- Shall we subclass sioc:created_at and sioc:modified_at from
> dc:date
> or dc_terms:issued and dc_terms:modified ?
+1
> -?- Shall we subclass sioc:link (used to describe link to a web page
> about the SIOC object - Post, User, ...) from dc:identifier ?
I say drop it. For posts and forums, the resource URI should be the
link. For users (and anything else), there's foaf:page/foaf:homepage
already. If anybody needs more, there's still dc:identifier.
Best,
Richard
Uldis Bojars
in this thread and raised again by Benja on #sioc) makes me return to
this topic. See question =2=.
On 6/1/06, Richard Cyganiak <ric...@cyganiak.de> wrote:
>
> > =1= Use foaf:Person instead of sioc:User for person's data
>
> <#richard> a foaf:Person .
> <#richard> foaf:holdsAccount <#richardInForum> .
> <#richardInForum> a sioc:User .
>
> That's not good, because <#richardInForum> would be both a
> foaf:OnlineAccount and a sioc:User, which seems wrong to me. Rename
> sioc:User to sioc:UserAccount?
sioc:User concept describes an online account. It used to describe
both an account and personal information associated with it but as
person's information was moved to a foaf:Person, the name remains.
> How would you model the association between an author and her posts?
>
> <#richard> sioc:creator_of <#post123> .
> or
> <#richardInForum> sioc:creator_of <#post123> .
>
> I think the first one is better, the association should be between
> the *person* and the post, not the *account* and the post. That's how
> dc:creator and foaf:maker work. Of course then you couldn't record
> any more that a single person posts from multiple accounts. From my
> point of view that would be acceptable.
Currently we associate a post with an online account used to create
this post. That allows to keep a link between posts and accounts they
were made from. What are your suggestions and why would you want to
loose this information?
> > =2= Changes to properties representing plain/rich content
> >
> > sioc:content is redundant - SIOC has sioc:description (subclass of
> > dc:description) using which is more consistent.
> Is sioc:content really the same as sioc:description? FWIW,
> dc:description is defined as "An account of the content of the resource.
> Description may include but is not limited to: an abstract, table of
> contents, reference to a graphical representation of content or a
> free-text account of the content." I read this as some kind of
> summary of the content.
Thanks for the comment. A number of people have already commented that
a dc:description is more appropriate for an abstract of a post than
for a full text content. Or, in other words, that by using
dc:description to describe full contents of a post we are implying
additional semantics on this property that it does not have.
We should not dc:description for post content then.
Where does that leave us? A simple solution is to use sioc:content.
> > =5= Changes to subject, topic, title
> > Separate subject information into:
> > - text (e.g., keywords) described by sioc:subject
> Please make it a subclass of rdfs:label.
... or use dc:subject (there's no difference in their meaning).
> > - resources (e.g., SKOS concepts) described by sioc:topic
> sioc:topic is pretty useless unless there's a method of actually
> defining the topics/categories/concepts. I'd say drop it. Any
> external vocabulary for describing topics, e.g. SKOS, already comes
> with an equivalent of sioc:topic.
Not sure about this. Using external vocabulary like SKOS for topics is
preferred but we can't guarantee that all SIOC data will always have
one. Currently there are no SKOS categories in the WordPress SIOC
export [yet], but if there is sioc:topic that helps already.
Uldis
Jack Park
> We should not dc:description for post content then.
>
> Where does that leave us? A simple solution is to use sioc:content.
then said in another context
> Not sure about this. Using external vocabulary like SKOS for topics is
> preferred but we can't guarantee that all SIOC data will always have
> one.
I interpret that to mean that some particular "topic" has been
assigned or named yet. I suppose there are other interpretations.
Maybe I'm off base here, but I cannot think of an instance of data of
any kind that doesn't exist within some context, eg, some subject or
basket of subjects. Let "subject" stand as a synonym for "topic."
That, of course, is difficult; the xml topic maps folks refer "topic"
as a kind of container that represents (proxies, stands for, whatever)
some "subject". It is my opinion that the SIOC ontology should make a
few ontological commitments to some terms, such as topic, subject, and
so forth; those commitments are necessary since the ontology is trying
to exist in several namespaces. If it is a requirement (as implied by
the quote) that a topic must exist prior to data being represented,
then I must be missing something.
Just a half EURO for the morning. No wait!...afternoon.
Cheers
Jack