Revisions to the SIOC Ontology

2006, May 12 - 04:04 — CaptSolo

Hi, All !

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 ]

--~--~---------~--~----~------------~-------~--~----~
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, June 9 - 11:28 — Cloud

SIOC ontology

Hi all -

Just some details of proposed ontology changes as commented on by Alex
below. I'll put in my 2c.

> ** Ontology
>
> - Post: content and content_encoded should be removed from the specs [1]

Sounds fine!

> - User: sioc:knows => moved to FOAF property
> remove first+last name => sioc:name [1]
> BTW, do we keep sioc:name ? or do we move to a new sioc:accountName /
login
> property ?

This is semantically more correct because it's not the User that knows
people or has a name, it's the associated foaf:Person.

> sioc:avatar => shall we use FOAF foaf:depiction or is the avatar
local for
> the forum ?

Yeah the avatar would be local to a forum, but maybe it is too Bulletin
Board specific as pointed out by Richard? But also this could be a
Gravatar as used in the blogosphere, and that is associated with an
e-mail address...

> - sioc:link => isn't rdf:about enough to get the URL from a Post ?

I don't think so - because some Posts will not have specific URLs and
their rdf:about would be the same - take comments on WordPress for
example - there's a #comment that links to all the comments but no URLs
for each comment "Post".

> - sioc:related_to => The specs say "determined implicity from topics or
> references", which means they can be infered from the topic / subject
of the
> post. So maybe that's not useful to keep it in the ontology as we can
> easilly infer it from other properties ?

Maybe the spec needs to be changed to say that is one possibility. I am
thinking of bulletin board systems that show you potentially related
posts, e.g. look at the end of
http://www.boards.us/forums/showthread.php?t=2124 or the similar posts
thing in WordPress.

> - sioc:has_sibling / sioc:sibling_of => If I understood well, I think
> has_sibling is a symetric property, so we don't need any inverse
relation.

Yep! Can drop the has_/_of even and just say sibling?

> - sioc:type => removed [1]
>
> More generally, I think that "Role" is a bit obscure at the moment,
> especially as there's no unified way to define a role. (In DC export, I
> export the roles as defined in the tool, which are litterals, and are - I
> think - different from the one WP has)

I have a similar problem. I want to define a subscriber to a forum.
But it's a bit "wordy" - to find all subscribers to a forum I need to
find all Users with Roles applying to Forums where the Role is of type
#moderator or something.

The Role idea seemed like a good idea because you wouldn't have to
define a million properties. I think this could be a good idea for the
modules or types file. This types file could have:

Forum: Blog, Mailing_List, USENET_Newsgroup, Bulletin_Board, ...
Role: Owner, Administrator, Moderator, Subscriber, Registered_User,

I think Uldis thought of having instances rather than classes for these
types.

> Regarding the version properties, what about moving it into a
> "SIOC-versionning" vocabulary, that would be a module / extension of
> "SIOC-core".
> I think it would be a good way to define a core + module, so that it will
> allow people
> 1) to see exactly the ontology is about
> 2) develope our / their own modules (eg: versionning module, auth module
> ...)

Yes, and also our thought too - we removed all these "extra" stuff that
we now want to put into a "types" module.

> Regarding trackback, I think we should subclass it from has_reply /
> reply_from, which will be the easiest way. (and so SPARQL get
comments will
> return the TBs)

If a reply is more general than a trackback - sounds fine. I guess all
trackbacks are distributed replies, but all distributed replies are not
trackbacks...

> Maybe some questions could be asked to sioc-dev.

Here we go :)

> Best,
>
> Alex.

[1]
http://groups.google.com/group/sioc-dev/browse_frm/thread/b8e3f8ceb73b29f5/#

Thanks,

John.
--

2006, June 14 - 19:18 — CaptSolo

SIOC ontology

Thanks a lot to all who commented!
Here's my 2c and some ontology changes.

> > - Post: content and content_encoded should be removed from the specs [1]
> > - User: sioc:knows => moved to FOAF property
> > remove first+last name => sioc:name [1]
> > - sioc:has_sibling / sioc:sibling_of => If I understood well, I think
> > has_sibling is a symetric property, so we don't need any inverse relation.
> > - sioc:type => removed [1]

Done - properties used in current exporters changed to
owl:DeprecatedProperty (and won't show up in the spec), sioc:knows,
sioc:sibling_of and sioc:type removed altogether.

Property sioc:has_sibling changed to owl:SymmetricProperty. It's name
does not imply any particular direction so it is be good to stay.

A question related to content / content_encoded properties - what
property shall we use instead of sioc:content? potential candidates are
sioc:description or dc:description.

> > BTW, do we keep sioc:name ? or do we move to a new sioc:accountName /
> login property ?

Using foaf:accountName to indicate the username of the account is a
possibility. Do we loose some semantics of sioc:name if we do so?

Just one thing - description of sioc:name says "The name of a User or a
Usergroup". What will we use to indicate the name of the group? (And do
Usergroups have account names at all?)

> > sioc:avatar => shall we use FOAF foaf:depiction or is the avatar
> local for the forum ?
>
> Yeah the avatar would be local to a forum, but maybe it is too Bulletin
> Board specific as pointed out by Richard? But also this could be a
> Gravatar as used in the blogosphere, and that is associated with an
> e-mail address...

Avatar is something specific to an account - quite often they have no
resemblance of the person in real life (which a depiction would
suggest). Gravatars should not require a special property as they are
associated with foaf:mbox.

Suggest that we keep sioc:avatar for now - since we are trying to make
SIOC generic enough so it can describe all these different kinds of
community sites it would make sense to keep avatar if it is required
for, say, bulleting boards.

BTW - when saying this - it would be good to have SIOC export from a
bulleting board (vBulletin, others). Then we would better see what is
needed and what is not.

> > - sioc:link => isn't rdf:about enough to get the URL from a Post ?
>
> I don't think so - because some Posts will not have specific URLs and
> their rdf:about would be the same - take comments on WordPress for
> example - there's a #comment that links to all the comments but no URLs
> for each comment "Post".

Agree to the next post by Richard: in WordPress the comments do have a
URIs though they do not have a page of their own.

In most of the cases rdf:about should be enough.

The idea behind sioc:link is to point to a human-readable
representation / original page containing this SIOC object. If dropping
sioc:link and assume that we want the user to be able to get to the
original post (e.g., to comment), there are 2 open questions:
1) will rdf:about always point to the original post (=can it be used to
get to the post/comment/...)?
2) how will we get to the original location for that small number of
SIOC objects who do not have a URI of their own? (imagine if WP did not
have fragment identifiers for comments).

How shall we answer these questions and shall we keep or delete
sioc:link?

> > - sioc:related_to => The specs say "determined implicity from topics or
> > references", which means they can be infered from the topic / subject
> of the
> > post. So maybe that's not useful to keep it in the ontology as we can
> > easilly infer it from other properties ?
>
> Maybe the spec needs to be changed to say that is one possibility. I am
> thinking of bulletin board systems that show you potentially related
> posts, e.g. look at the end of
> http://www.boards.us/forums/showthread.php?t=2124 or the similar posts
> thing in WordPress.

Please suggest changes if needed.

Part of the relations can be inferred from the topic / subject / ...
But even in this case it may be worthwhile to keep this inferred result
in the knowledge base. Besides, there can be other relations (e.g.,
explicitly said by the user) that can not be inferred.

We are not using sioc:related_to much now, but it sounded interesting
enough to put into the ontology. It acts as a "loose" relation property
(similar foaf:knows in FOAF) - it may be useful for keeping different
type of relations, but at the same time if you want to keep more
specific information, you may want to subclass it or create a new
property (e.g., sioc:links_to).

That's all for now.

And thanks again to everybody for the input into developing SIOC! :)
With this speed of community effort it's even hard to keep up with the
pace.

Best,
Uldis

[ http://captsolo.net/info/ ]

2006, June 15 - 16:24 — Richard Cyganiak

SIOC ontology

Hi Uldis,

Just one point:

On 14 Jun 2006, at 21:11, Uldis Bojars wrote:
>>> - sioc:link => isn't rdf:about enough to get the URL from a Post ?
...
> In most of the cases rdf:about should be enough.
>
> The idea behind sioc:link is to point to a human-readable
> representation / original page containing this SIOC object. If
> dropping
> sioc:link and assume that we want the user to be able to get to the
> original post (e.g., to comment), there are 2 open questions:
> 1) will rdf:about always point to the original post (=can it be
> used to
> get to the post/comment/...)?

That would be good practice for sioc:Post, because everything you say
about a sioc:Post is really about the web page where you can see the
post. So there's no need to introduce new URIs for posts -- just use
the existing URL.

> 2) how will we get to the original location for that small number of
> SIOC objects who do not have a URI of their own? (imagine if WP did
> not
> have fragment identifiers for comments).

Well, if it doesn't have a URL, then linking to the original location
is impossible, no matter if you keep or drop sioc:link, isn't it? In
other words, the question doesn't make that much sense.

I also don't think it happens much. The vast majority of community
platform software does assign permalinks to items like comments,
because people *do* want to link to these things.

That being said, sioc:content (or its replacement in the new version)
could be used to include the content directly.

> How shall we answer these questions and shall we keep or delete
> sioc:link?

+1 for delete. There's already rdfs:seeAlso and foaf:page if the need
arises in some special situation.

Best,
Richard

2006, June 15 - 16:24 — CaptSolo

SIOC ontology

Hi, Richard!

> > 2) how will we get to the original location for that small number of
> > SIOC objects who do not have a URI of their own? (imagine if WP did
> > not
> > have fragment identifiers for comments).
>
> Well, if it doesn't have a URL, then linking to the original location
> is impossible, no matter if you keep or drop sioc:link, isn't it? In
> other words, the question doesn't make that much sense.

To clarify the question - it is the situation when there is a page
(identified with a URL) that has a number of SIOC objects (e.g.,
comments) which do not have URLs of their own.

In such case you can't address them individually, yet you can point to
a web page where these items are located. Using it as rdf:about would
be wrong.

> I also don't think it happens much. The vast majority of community
> platform software does assign permalinks to items like comments,
> because people *do* want to link to these things.

Agree. It should not happen often.

> That being said, sioc:content (or its replacement in the new version)
> could be used to include the content directly.

Including content is not a problem - we are already doing it. The
problem is how to provide a link to the original, human readable page -
for example, to let reader respond to a comment (or to verify that the
page actually says what he sees in SIOC data).

Maybe there is a Dublin Core property that we can use.
(Update: no need any more, foaf:page mentioned below should do it)

When talking about responding to comments - maybe we need a property
(re-use existing or add to SIOC) to show where the reader can respond /
provide feedback?

> > How shall we answer these questions and shall we keep or delete
> > sioc:link?
>
> +1 for delete. There's already rdfs:seeAlso and foaf:page if the need
> arises in some special situation.

foaf:page looks like what is needed.
it must be safe to use it - its domain is owl:Thing and range -
foaf:Document.

Uldis

[ http://captsolo.net/info/ ]

2006, June 19 - 14:47 — Richard Cyganiak

SIOC ontology

On 15 Jun 2006, at 15:41, Uldis Bojars wrote:
>>> 2) how will we get to the original location for that small number of
>>> SIOC objects who do not have a URI of their own? (imagine if WP did
>>> not
>>> have fragment identifiers for comments).
>>
>> Well, if it doesn't have a URL, then linking to the original location
>> is impossible, no matter if you keep or drop sioc:link, isn't it? In
>> other words, the question doesn't make that much sense.
>
> To clarify the question - it is the situation when there is a page
> (identified with a URL) that has a number of SIOC objects (e.g.,
> comments) which do not have URLs of their own.
>
> In such case you can't address them individually, yet you can point to
> a web page where these items are located. Using it as rdf:about would
> be wrong.

That's a good point, you can still point to a page containing the
items in question.

As you said, it doesn't look like a common case and re-using
foaf:page should be fine.

(snip)
> When talking about responding to comments - maybe we need a property
> (re-use existing or add to SIOC) to show where the reader can
> respond /
> provide feedback?

The reply form is usually easily found on the post's web page. I
think a new property wouldn't add a lot of value.

Richard

>
>>> How shall we answer these questions and shall we keep or delete
>>> sioc:link?
>>
>> +1 for delete. There's already rdfs:seeAlso and foaf:page if the need
>> arises in some special situation.
>
> foaf:page looks like what is needed.
> it must be safe to use it - its domain is owl:Thing and range -
> foaf:Document.
>
> Uldis
>
> [ http://captsolo.net/info/ ]
>
>
> >
>

2006, June 14 - 20:12 — Fred

SIOC ontology

Hi,

> Done - properties used in current exporters changed to
> owl:DeprecatedProperty (and won't show up in the spec), sioc:knows,
> sioc:sibling_of and sioc:type removed altogether.
>
> Property sioc:has_sibling changed to owl:SymmetricProperty. It's name
> does not imply any particular direction so it is be good to stay.

Good choice.

> A question related to content / content_encoded properties - what
> property shall we use instead of sioc:content? potential candidates are
> sioc:description or dc:description.

We could use sioc:description and map dc:description. I think the question is:
how do we want people using SIOC: only with its terms or in conjunction with
other ontologies like DC and FOAF? You already make the choice vis-a-vis the
FOAF ontology, but what is the "granularity" you need/wish to have? Where do we
draw the line?

> Avatar is something specific to an account - quite often they have no
> resemblance of the person in real life (which a depiction would
> suggest). Gravatars should not require a special property as they are
> associated with foaf:mbox.
>
> Suggest that we keep sioc:avatar for now - since we are trying to make
> SIOC generic enough so it can describe all these different kinds of
> community sites it would make sense to keep avatar if it is required
> for, say, bulleting boards.

It's good for now, but I think it would be a good idea to rely all the user's
personal information to FAOF. However, it makes sense to leave the sioc:avatar
as-is because it represent the avatar of a user-account and not an individual
(so I can have an avatar related to one of my user-account, and another one that
really depict myself (for example, an avatar for a service account for my job,
another one for my blog, etc)).

> > > - sioc:link => isn't rdf:about enough to get the URL from a Post ?
> >
> > I don't think so - because some Posts will not have specific URLs and
> > their rdf:about would be the same - take comments on WordPress for
> > example - there's a #comment that links to all the comments but no URLs
> > for each comment "Post".
>
> The idea behind sioc:link is to point to a human-readable
> representation / original page containing this SIOC object. If dropping
> sioc:link and assume that we want the user to be able to get to the
> original post (e.g., to comment), there are 2 open questions:
> 1) will rdf:about always point to the original post (=can it be used to
> get to the post/comment/...)?
> 2) how will we get to the original location for that small number of
> SIOC objects who do not have a URI of their own? (imagine if WP did not
> have fragment identifiers for comments).

I think it is a good idea to keep the sioc:link as-is with the definition you
just provided.

I could take a simple example to explain why. Right now, as you probably know, I
implemented SIOC in Talk Digger. For now, the resources described (about=) are
real web page publicly accessable. However, it is possible that in the future I
need to change some things in the architecture of the system and change some
paths. In that case, I would have to change the URI of the resource I am
describing. But what happen if a triple store somewhere else in the World was
crawling/using my data? He will lose the reference to the resources and will not
be able to relate anything to what he have in store.

By using sioc:link, I will be able to continue to describe my resources using my
old URI naming system, and I will be able to "link" to the "accessible-
resources".

Does it make sense?

> And thanks again to everybody for the input into developing SIOC! :)
> With this speed of community effort it's even hard to keep up with the
> pace.

And thank to you for managing its development!

Salutations,

--
Frederick Giasson

www.fgiasson.com
www.talkdigger.com

2006, June 15 - 16:24 — Richard Cyganiak

SIOC ontology

Hi Frederick,

On 14 Jun 2006, at 21:43, Frederick Giasson wrote:
> I think it is a good idea to keep the sioc:link as-is with the
> definition you
> just provided.
>
> I could take a simple example to explain why. Right now, as you
> probably know, I
> implemented SIOC in Talk Digger. For now, the resources described
> (about=) are
> real web page publicly accessable.

Good!

> However, it is possible that in the future I
> need to change some things in the architecture of the system and
> change some
> paths. In that case, I would have to change the URI of the resource
> I am
> describing. But what happen if a triple store somewhere else in the
> World was
> crawling/using my data? He will lose the reference to the resources
> and will not
> be able to relate anything to what he have in store.

Right. That's what we call a "dead link" ;-)

> By using sioc:link, I will be able to continue to describe my
> resources using my
> old URI naming system, and I will be able to "link" to the
> "accessible-
> resources".
>
> Does it make sense?

Yes, the problem is real, but I would approach it differently. There
are two possible answers:

First: You changed all your URLs and people have referenced the old
URLs? So what? Stuff breaks on the web, people get 404s, there are
dead links, that's just the way it works. Everybody is used to it and
will work around it. sioc:link wouldn't really fix that problem -- it
only means now there are *two* URIs per post that can break instead
of one. If you can't keep your links stable, then how can we expect
you to keep your resource identifiers stable?

Second: Cool URIs don't change. You should have taken the time to
develop a stable URI scheme before you started. There's things like
mod_rewrite that help. And if you really have to change URIs, put
HTTP redirects in place and nobody will notice. So you can avoid the
broken link problem yourself by doing a little bit of extra
investment. Don't expect sioc:link to fix a basic property of the web
for you ;-)

Sorry if I'm sounding a bit smug here -- I'm obviously talking from a
theorist's perspective here, and I know that things are rarely that
simple when you build real-world stuff. I just want to say that
changing URLs *are* a problem on the web and always were and always
will be, and SIOC won't fix that.

Yours,
Richard

2006, June 15 - 16:24 — Fred

SIOC ontology

Hi Richard,

> Second: Cool URIs don't change. You should have taken the time to
> develop a stable URI scheme before you started. There's things
like
> mod_rewrite that help. And if you really have to change URIs, put
> HTTP redirects in place and nobody will notice. So you can avoid
the
> broken link problem yourself by doing a little bit of extra
> investment. Don't expect sioc:link to fix a basic property of the
web
> for you ;-)

>
> Sorry if I'm sounding a bit smug here -- I'm obviously talking from
a
> theorist's perspective here, and I know that things are rarely
that
> simple when you build real-world stuff. I just want to say that
> changing URLs *are* a problem on the web and always were and
always
> will be, and SIOC won't fix that.

Hehheeh, nah, don't worry. It was an example to show how *it could*
be useful. However you are right by saying that it is the way the Web
works since the begenning and that the way the semantic web will
certainly work too.

But in that case, the most beautiful and stable uri schemas is
probably one that as nothing to do with URLs, no? If so, the sioc:
link proproty would be more than essential in such a case, no?

I totally agree with what you said in that email, but what would you
do? Getting rid of the sioc:link property or leaving it as it is?

Thanks for the answer!

Salutations,

--
Frederick Giasson

www.fgiasson.com
www.talkdigger.com

2006, June 19 - 14:47 — Richard Cyganiak

SIOC ontology

Hi Frederick,

On 15 Jun 2006, at 14:29, Frederick Giasson wrote:
>> Second: Cool URIs don't change. You should have taken the time to
>> develop a stable URI scheme before you started. There's things
> like
>> mod_rewrite that help. And if you really have to change URIs, put
>> HTTP redirects in place and nobody will notice. So you can avoid
> the
>> broken link problem yourself by doing a little bit of extra
>> investment. Don't expect sioc:link to fix a basic property of the
> web
>> for you ;-)
>
>>
>> Sorry if I'm sounding a bit smug here -- I'm obviously talking from
> a
>> theorist's perspective here, and I know that things are rarely
> that
>> simple when you build real-world stuff. I just want to say that
>> changing URLs *are* a problem on the web and always were and
> always
>> will be, and SIOC won't fix that.
>
> Hehheeh, nah, don't worry. It was an example to show how *it could*
> be useful. However you are right by saying that it is the way the Web
> works since the begenning and that the way the semantic web will
> certainly work too.
>
> But in that case, the most beautiful and stable uri schemas is
> probably one that as nothing to do with URLs, no?

Ask that question to three RDF folks and you will get four different
answers. Here's mine: Yes, non-URL schemes like URNs and the tag:
scheme are more stable than HTTP URIs. But more beautiful? No. I
think the real beauty of URIs is that you can actually retrieve a
representation of the resource that the URI identifies. That's the
really important function of a URI. And you lose that with the urn:
and tag: schemes.

> If so, the sioc:link proproty would be more than essential in such
> a case, no?

You are right, it's possible to get the best of two worlds with
sioc:link. A stable tag: or urn: URI as the identifier, and sioc:link
for retrieving a representation. But that's additional complexity.
You need two URIs instead of just one.

With HTTP URIs, you can use one URI as both name and address. If you
put a bit of care into designing and maintaining your URI space, then
you also get stability. Every publisher manages their own HTTP URI
space and can decide for themselves how much effort they want to
spend on stability. I think that's a pretty good solution.

> I totally agree with what you said in that email, but what would you
> do? Getting rid of the sioc:link property or leaving it as it is?

As I said in the other post, I'd be in favor of removing sioc:link.
IMO it introduces ambiguity and potential confusion. The best place
for the post's URL is as the post's identifier, not in a separate
property.

Just my €0.02.

Cheers,
Richard

>
>
> Thanks for the answer!
>
>
> Salutations,
>
>
>
> --
> Frederick Giasson
>
> www.fgiasson.com
> www.talkdigger.com
>
>
>
> >
>

2006, June 19 - 14:47 — Fred

SIOC ontology

Hi Richard,

> As I said in the other post, I'd be in favor of removing sioc:
link.
> IMO it introduces ambiguity and potential confusion. The best
place
> for the post's URL is as the post's identifier, not in a separate
> property.

I agree with you: keep it as simple as possible, not simpler (
Einstein).

I just read one blog post from someone on the mailing list (don't
remember who) that was saying that we should focus on cut-off the
redundancy with other existing ontologies. I agree with him and
deprecating the sioc:link property goes in that trend. I think we
should have a discussion about the use of properties like sioc:
description (or dc:description), etc.

Salutations,

Fred

2006, June 14 - 16:55 — Richard Cyganiak

SIOC ontology

On 9 Jun 2006, at 13:17, John Breslin wrote:
>> - sioc:link => isn't rdf:about enough to get the URL from a Post ?
>
> I don't think so - because some Posts will not have specific URLs and
> their rdf:about would be the same - take comments on WordPress for
> example - there's a #comment that links to all the comments but no
> URLs
> for each comment "Post".

I just want to point out that each Wordpress comment does indeed have
its own URL, something like:

http://dowhatimean.net/2006/06/more-cool-sparqlajax-stuff#comment-7739

I agree with the original poster, the URL should be used directly to
identify the comment.

In the case where a Post really doesn't have a URL, the post won't
have a sioc:link either, and you can fall back to using a blank node
or a non-resolvable URI for the comment.

Cheers,
Richard

2006, June 14 - 16:55 — Cloud

Potential ontology additions

Just want to discuss future additions to the ontology, as a followup to
the previous changes...

Proposed additions... Feel free to correct.

sioc:Community
Description: This class can be used to describe a localised or
distributed community.

sioc:part_of
Description: This property is used to link a concept to a community
that it is part of.
Domain: (not specifed)
Range: sioc:Community
Inverse: has_part

sioc:has_part
Description: This property is used to link a community to its
constituent parts.
Domain: sioc:Community
Range: (not specified)
Inverse: part_of

sioc:trackback_to
Description: This property links a reply post to the original post
it sent a trackback ping to.
Domain: sioc:Post
Range: sioc:Post
Inverse: trackback_from
Subproperty of: reply_of

sioc:trackback_from
Description: This property links a post to a reply from which it has
received a trackback ping from.
Domain: sioc:Post
Range: sioc:Post
Inverse: trackback_to
Subproperty of: has_reply

Other ideas:

Do we need caching properties for aggregated content or is this beyond
the scope of SIOC and more related to context? A blog post is
republished by an aggregator, would it be useful to know at what
time/date the post was cached?

J.
--

2006, June 14 - 16:55 — Fred

Potential ontology additions

Hi John,

> sioc:Community
> Description: This class can be used to describe a localised or
> distributed community.

Could be a good idea, but we should think about what is part_of and
has_part of a "community". Is it a User? a new entity? And we also
have to place that new concept in relation with all the other ones
(Site, Forum, Usergroup).

In fact, my question is: what would be the difference between a
Usergroup and a Community (semantically)?

Because when I read the description of a Usergroup, it looks like a
Community, doesn't it?: "A set of Users (accounts) who have a common
purpose or interest. Can be used for access control purposes."

A Usergroup regroup users with commin puspose and/or interests,
Communities regroup users considering what? I think we should define
that.

>
> sioc:part_of
> Description: This property is used to link a concept to a
community
> that it is part of.
> Domain: (not specifed)
> Range: sioc:Community
> Inverse: has_part
>
> sioc:has_part
> Description: This property is used to link a community to its
> constituent parts.
> Domain: sioc:Community
> Range: (not specified)
> Inverse: part_of
>
> sioc:trackback_to
> Description: This property links a reply post to the original
post
> it sent a trackback ping to.
> Domain: sioc:Post
> Range: sioc:Post
> Inverse: trackback_from
> Subproperty of: reply_of
>
> sioc:trackback_from
> Description: This property links a post to a reply from which
it has
> received a trackback ping from.
> Domain: sioc:Post
> Range: sioc:Post
> Inverse: trackback_to
> Subproperty of: has_reply

If I understand right, the trackback thing only apply to Post that
use the "trackback" protocol? In that case, it would mostly (if not
only) apply to some blog posts, right? If so, I am not sure that it
is a good idea considering that trackbacks are dying considering the
spam problems.

My question here is: what is the "added-value" of trackbacks over
normal "has_reply". Is it really useful to include two new properties
to explicit the fact that a reply (a link) have been created using a
trackback? Personally I don't think so.

> Do we need caching properties for aggregated content or is this
beyond
> the scope of SIOC and more related to context? A blog post is
> republished by an aggregator, would it be useful to know at what
> time/date the post was cached?

Tell me if I am wrong, but the has_sibling and sibling_of properties
could be use to "tag" replicated posts, right? In that case, a "has_
sibling" post (the replicated one by an aggregator) could also add
the "create_at" property. This way, we would know when it have been
replicated.

I hope it helps you.

Take care,

Salutations

--
Frederick Giasson

www.fgiasson.com
www.talkdigger.com

2006, July 14 - 12:59 — CaptSolo

Potential ontology additions

On 6/9/06, Frederick Giasson wrote:
> > sioc:Community
> > Description: This class can be used to describe a localised or
> > distributed community.
>
> Could be a good idea, but we should think about what is part_of and
> has_part of a "community". Is it a User? a new entity? And we also
> have to place that new concept in relation with all the other ones
> (Site, Forum, Usergroup).
>
> In fact, my question is: what would be the difference between a
> Usergroup and a Community (semantically)?

sioc:Community sounds like a good idea. Christoph commented earlier
that a community is something that should have been in a SIOC ontology
from the very begining..

A summary from a chat with Alex and John about sioc:Community:
- a sioc:Community acts as a container for all kinds of SIOC objects
(maybe also other, non-SIOC objects?) and groups them together as
belonging to this community.

This is the difference of sioc:Community and sioc:Usergroup:
- a usergroup keeps together a number of users (e.g., authors,
administrators, ...)
- sioc:Community keeps together a number of different objects (Sites,
people, ...)

E.g., a semantic web community may consist of a people, Planet RDF
website, #swig web channel and its web scratchpad, some mailing lists,
...

> A Usergroup regroup users with commin puspose and/or interests,
> Communities regroup users considering what? I think we should define
> that.

Yes, we should define what a Community is and how we will use it.

Related:
- http://b4mad.net/datenbrei/archives/2006/05/22/sioc-from-foafroll/
- http://apassant.net/blog/2006/06/29/97-rdf-export-of-sioc-wiki-content

I see that Alex already uses a sioc:Community is "RDF Export of SIOC
Wiki Content" as a container for sioc:Site(s). One could ask in this
case, though, what is the benefit from using sioc:Community and
sioc:Site here over existing ways to specify a collection of URLs (to
crawl or to import into RSS readers) using FOAF, OPML, etc...

> If I understand right, the trackback thing only apply to Post that
> use the "trackback" protocol? In that case, it would mostly (if not
> only) apply to some blog posts, right? If so, I am not sure that it
> is a good idea considering that trackbacks are dying considering the
> spam problems.

Trackback is used in a variety of sites (though if we look only at
community sites it's mainly blogs) - the idea is good, but the problem
is spam. This problem has solutions, I believe.

A benefit of trackbacks is that it explicitly indicates a relation
between posts. Semantics of the relation might be unclear but it is
already better than nothing (and we can work on semantics of the
relation further on).

One reason for adding trackbacks is to be able to express in SIOC as
much as possible of the information on an community site. Trackbacks
are part of such information (e.g., in b2evolution there are 3 types
of comment objects - 'comments', 'trackback' and 'pingback').

If SIOC can keep all the details about community site it may act as a
"medium" to transfer information between community sites and even
migrate data from one site to another. This may be a tough call though
(some information might not be available in SIOC export), but why deny
ourselves the terms to express what is inside a site?

> My question here is: what is the "added-value" of trackbacks over
> normal "has_reply". Is it really useful to include two new properties
> to explicit the fact that a reply (a link) have been created using a
> trackback? Personally I don't think so.

See above - if we don't distinguish between them we loose some
information (and loose the ability to recreate the same structures
elsewhere).

What we may think about is if we can better integrate trackbacks into
the existing SIOC model.

Uldis

[ http://captsolo.net/info/ ]

2006, July 14 - 12:59 — Christoph Görn

Potential ontology additions

Good morning, please find my comments below...

Am 05.07.2006 um 05:43 schrieb CaptSolo:
On 6/9/06, Frederick Giasson wrote:
>> If I understand right, the trackback thing only apply to Post that
>> use the "trackback" protocol?
>> My question here is: what is the "added-value" of trackbacks over
>> normal "has_reply".
> See above - if we don't distinguish between them we loose some
> information (and loose the ability to recreate the same structures
> elsewhere).

Keeping in mind the discussion on #swig i took a look at the rss
trackback module (http://madskills.com/public/xml/rss/module/
trackback/) and it says:
"trackback:about is a sub-element of an RSS item, and contains a
TrackBack URL that was pinged in reference to this RSS item. Each RSS
item may contain zero or more instances of trackback:about."

Understanding (and defining) a sioc:Post as a rss1.0:item would
enable two things:

1) semantics of trackbacks are defined by RSS1.0 trackback module, and

2) SIOC goal of describing the structure of a Community (and it's
Posts) with a focus on exchangability is reached

sioc:Post is already a foaf:Document, to better describe weblogs we
should make it a subclass of rss1:item and skip sioc:trackback* from
SIOC.

Making statements about what protocol was used to make a comment
extends SIOC's domain from "describe community structures" to
"describe community structures and technical infrastructure used by
the community".

Christoph

--
Christoph Görn
http://B4mad.Net/FOAF/goern.rdf#goern

Usability schmusability... where's the part where we talk about how
this helps users kick ass?

2006, July 14 - 12:59 — CaptSolo

Potential ontology additions

Christoph Görn wrote:
>
> Keeping in mind the discussion on #swig i took a look at the rss
> trackback module (http://madskills.com/public/xml/rss/module/
> trackback/) and it says:
> "trackback:about is a sub-element of an RSS item, and contains a
> TrackBack URL that was pinged in reference to this RSS item. Each RSS
> item may contain zero or more instances of trackback:about."
>
> Understanding (and defining) a sioc:Post as a rss1.0:item would
> enable two things:
>
> 1) semantics of trackbacks are defined by RSS1.0 trackback module, and
>
> 2) SIOC goal of describing the structure of a Community (and it's
> Posts) with a focus on exchangability is reached

We were looking at the TrackBack module before and were thinking to
reuse or invent new properties. You have good arguments for reuse.

However, there are couple of issues / questions to answer:

1) there is no RDF schema for RSS TrackBack module, hence no machine
readable info about the schema / its semantics

2) how would you describe the other direction - that a particular post
B has received trackback from post A ?

3) how would you express that the trackback was done (sent/received) at
a particular time? trackback:about only allows to point to the URL that
has been track-backed.

Subclassing sioc:Post from rss:item makes sense - unless there're some
conflicts arising (which I do not see).

> Making statements about what protocol was used to make a comment
> extends SIOC's domain from "describe community structures" to
> "describe community structures and technical infrastructure used by
> the community".

It depends if we only want to extract information from community sites
or also "reconstruct" as much information as possible about them.

Being able to use SIOC as a transport between 2 community sites is
tempting, although not the main reason why we have or need SIOC.

Good thing is that in the solution you proposed we can distinguish
between comments and trackbacks - so we keep the "technical data".

Best,
Uldis

[ http://captsolo.net/info/ ]

2006, June 2 - 16:37 — Richard Cyganiak

Revisions to the SIOC Ontology

Some comments on http://groups.google.com/group/sioc-dev/
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> .

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

2006, September 2 - 17:57 — CaptSolo

Revisions to the SIOC Ontology

Comments about sioc:content vs. dc:description (described by Richard
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 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

[ http://captsolo.net/info/ ]

2006, September 2 - 17:57 — Jack Park

Revisions to the SIOC Ontology

From below, Uldis said:
> We should not dc:description for post content then.
>
> Where does that leave us? A simple solution is to use sioc:content.
+1
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.
One what? I'll take "topic".
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

On 8/11/06, Uldis Bojars wrote:
>
> Comments about sioc:content vs. dc:description (described by Richard
> 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 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
>
> [ http://captsolo.net/info/ ]
>
> >
>

2006, May 30 - 09:46 — terraces

Revisions to the SIOC Ontology

Hi all,

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).

Best,

Alex.

[1] http://www.w3.org/2003/01/geo/

Best regards,
Uldis

[
http://captsolo.net/info/
]
[ CaptSolo @ #foaf and #swig ]

2006, May 31 - 21:01 — Fred

sioc:owned_by OR rdfs:seeAlso ?

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

2006, May 30 - 09:46 — CaptSolo

Revisions to the SIOC Ontology

Alex,

Thanks for your comments. :)

On 5/22/06, Alexandre Passant 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

[ http://captsolo.net/info/ ]

Revisions to the SIOC Ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

SIOC ontology

Potential ontology additions

Potential ontology additions

Potential ontology additions

Potential ontology additions

Potential ontology additions

Revisions to the SIOC Ontology

Revisions to the SIOC Ontology

Revisions to the SIOC Ontology

Revisions to the SIOC Ontology

sioc:owned_by OR rdfs:seeAlso ?

Revisions to the SIOC Ontology

Primary links

Syndicate

User login