Re: SIOC ontology
John Breslin
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.
--
Richard Cyganiak
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
John Breslin
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.
--
Frederick Giasson
> 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.
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
Uldis Bojars
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
Frederick Giasson
> 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,
Richard Cyganiak
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
Richard Cyganiak
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
Frederick Giasson
> 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!
Uldis Bojars
> > 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
Richard Cyganiak
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
Richard Cyganiak
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
Frederick Giasson
> 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
CaptSolo
> > 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
Christoph Görn
Am 05.07.2006 um 05:43 schrieb CaptSolo:
On 6/9/06, Frederick Giasson <fr...@fgiasson.com> 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 <go...@B4mad.Net>
http://B4mad.Net/FOAF/goern.rdf#goern
Usability schmusability... where's the part where we talk about how
this helps users kick ass?
Uldis Bojars
>
> 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