SIOC types and posts with embedded/attached content
John Breslin
I'm just kicking off a discussion to try and finalise some additions we
are trying to make to SIOC to allow it to cover many other "Web 2.0"
community sites where content is posted in a forum or container area of
a site and then may also be commented on (like in a discussion thread).
Some examples are Flickr, Upcoming.org, YouTube, SlideShare, etc.
For a picture of what we have in mind, see:
http://www.johnbreslin.com/blog/2007/03/01/linking-personal-posted-content-across-communities/
The inner layer is a person (in FOAF), the next layer is their user
accounts (FOAF, SIOC) and the outer stuff is the posted content (text,
files, associated metadata) in SIOC.
--------------------------------------------------------------------------------
(1) SIOC types
Kingsley created a nice list of SIOC types, i.e. types of various forums
/ containers and the posted content therein. I am going through this
list, adding some new types and trying to choose generic names where
possible. Note that these types are totally optional, and could be used
as an additional rdf:type so that tools that use sioc:Forum / Post would
still work okay.
The current list is at http://wiki.sioc-project.org/index.php/TypesModule
Ideas can be added to the page.
--------------------------------------------------------------------------------
(2) Posts and connected content (linked or embedded files or metadata)
So far, sioc:Posts have content, attachment and links_to properties
which cover a lot of discussion content scenarios.
It seems that we may still need a few more properties, e.g.
content_enhanced, embeds, etc.
The content_enhanced could be HTML-enhanced text, text with BB / wiki
codes, or maybe even a series of chunks of plain text and RDF metadata.
This property could also link to an AtomOWL Content object. Uldis
proposed sioc:body for this property some time back.
The embeds property could allow files to be viewed (e.g. remote video
files) or embedded metadata to be incorporated (e.g. in some structured
/ semantic blog posts, so that embeds -> object with metadata) in a
post. There may be a distinction between something that is attached and
something that is embedded - the former may not be displayed in the post
whereas the latter is - and something that is attached may also be embedded.
Another alternative is to use something instead of attachment / embeds
that can be used interchangeably, e.g. includes or contains (although
the latter confuses with sioc:has_container). This would remove
ambiguity over which to use (if someone won't use both).
Myself and Uldis have been wracking our heads trying to come up with the
best way to do this, so it'd be good to have your ideas on this. The
names content_enhanced or embeds are just ideas, better ones are welcome.
--------------------------------------------------------------------------------
(3) > Forums, Posts
Another suggestion from Kingsley was to have something greater than the
concept of a Forum so that posted content could be grouped together
(e.g. book reviews in a review channel, etc.). This would involve
superclasses of Forum and Post (and maybe Site), e.g. Container and
Content (and Space) or something like that. I'm almost afraid to
introduce such terms as we are perhaps creating something that can
describe anything, rather than online communities. For now, I'd hope
that solutions for (1) and (2) will suffice, and may also be more
semantically constrained.
--------------------------------------------------------------------------------
That's it so far, opinions welcome!
John.
--
See Uldis' earlier post to SWEO:
http://lists.w3.org/Archives/Public/public-sweo-ig/2007Feb/0180.html
--
Dr. John Breslin
DERI, NUI Galway
http://sw.deri.org/~jbreslin/
john.b...@deri.org
John Breslin
below for latest details of proposed new SIOC types. All going well, we
should be able to implement these next week...
http://www.johnbreslin.com/blog/2007/03/03/proposed-classes-for-sioc-types-module/
Thanks for the messages offlist.
J.
--
John Breslin wrote:
> Hi all -
>
> I'm just kicking off a discussion to try and finalise some additions we
> are trying to make to SIOC to allow it to cover many other "Web 2.0"
> community sites where content is posted in a forum or container area of
> a site and then may also be commented on (like in a discussion thread).
> Some examples are Flickr, Upcoming.org, YouTube, SlideShare, etc.
>
> For a picture of what we have in mind, see:
>
>
>
...
Alexandre Passant
I finally had a look at the posts, the wiki and schemas.
I agree with the "Certain" types of the wiki page (BTW, It was spammed again!).
I think that's important - from the Online Community point of view -
to mention a post is from a Wiki, a blog, an e-mail ... since it is
what makes its own nature.
Yet, I've got a different feeling with other types.
I think telling a post / or a forum is en EventPost, LocationPost ...
is not about its nature, but about its content.
And by saying that, we'll merge the aspects of defining a class and
its properties; if I refer to some notions of how to define this in
upper ontologies such as DOLCE [1] ... a class must be defined when
things won't change, else use property.
Their example is something like Person is a class, Musician is a
"quality", since it will always be a person, but can be another kind
of artist in the future.
I think that the same distinction should be done between what kind of
post is it (blog, wiki ...) and what is it about (event, people ...)
Here, I rather think we should have a best practive saying that if
you're blogging about an event use a "sioc:Post sioc:embeds ical:Event
(if I understood well the meaning of embed) statement to mention it,
with the given types table that list a lot of interesting types to be
used in Web 2.0 communities.
And would consider as real types, as subclass of sioc:Post, only a few as
- BlogPost
- MailMessage
- BoardPost
- WikiArticle
- PodcastPost
- BookmarkPost
- PollEntry
and maybe comment
* Maybe I missed something about Container / Space, but I can't see
what - still in this scope - what brings to the model ? Or maybe a top
class besides Forum / Site is enought if we want to say "A space that
contains Web 2.0 things" ?
Best,
Alex.
[1] http://www.loa-cnr.it/DOLCE.html
john.b...@deri.org
> * Maybe I missed something about Container / Space, but I can't see
> what - still in this scope - what brings to the model ? Or maybe a top
> class besides Forum / Site is enought if we want to say "A space that
> contains Web 2.0 things" ?
Yes, only some of those things should be considered subtypes of Forum,
the others would be types of Containers...
The images on
http://www.johnbreslin.com/blog/2007/03/03/proposed-classes-for-sioc-types-module/ should hopefully show the subclassing a bit clearer (this has changed from that proposed on the wiki
page).
Thanks,
John.
--
capt...@gmail.com
> * Maybe I missed something about Container / Space, but I can't see
> what - still in this scope - what brings to the model ? Or maybe a top
> class besides Forum / Site is enought if we want to say "A space that
> contains Web 2.0 things" ?
All of the things we want to describe (video, bookmarks, CVs, reviews,
...) are items (or objects), but not all of them fall within a more
specific definition of a Post. Similarly, not all collections of items
are discussion forums - e.g., a "file briefcase" is not.
Indeed a [Container / Space] is something that contains things or
items. sioc:Forum is a subclass of Container. And sioc:Post would be a
subclass of an item.
Uldis
capt...@gmail.com
> (1) SIOC types
and
> (3) > Forums, Posts
[ + Containers / Items ]
The list of SIOC types at [1] looks good. There may be some
fine-tuning of SIOC types as we implement them, some properties may be
moved up from Post to Item, but all in all it is a good start and lets
us move forward.
[1] http://www.johnbreslin.com/blog/2007/03/03/proposed-classes-for-sioc-types-module/
> (2) Posts and connected content (linked or embedded files or metadata)
>
> So far, sioc:Posts have content, attachment and links_to properties
> which cover a lot of discussion content scenarios.
>
> It seems that we may still need a few more properties, e.g.
> content_enhanced, embeds, etc.
>
> The content_enhanced could be HTML-enhanced text, text with BB / wiki
> codes, or maybe even a series of chunks of plain text and RDF metadata.
> This property could also link to an AtomOWL Content object. Uldis
> proposed sioc:body for this property some time back.
To abstract a little, we may look at Post/Item and 3 kinds of
properties / relations related to it:
a) Full content of a post/item.
We need a property that allows to express full content of a post (what
you'd call a body of a post), in different representations. And need
to be able to tell what representation this content is in.
[GNU] made an earlier suggestion how to do this in [2] using Atom/OWL.
We still need a property that would link a Post/Item to aowl:Content
and possible candidate names are body (as proposed in earlier posts),
content_enhanced, or any new suggestions.
[2] http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-atomowl-a-new-way-to-describe-content/
We can then model all different versions of content in SIOC using this
pattern and attach appropriate MIME type to them. E.g., a post
description can contain both its content in Wiki markup and in HTML.
Another usage of this pattern is to represent versions of a post in
different languages.
Existing properties used SIOC to describe post content: sioc:content,
content:encoded.
b) "Things" contained within / linked to from a Post/Item
A Post/Item may contain or link to objects which we may want to tell
more about. Things contained within a post can be an Image, or a
Review. Things linked to from an item can be a video or a
presentation. There may also be attachments to an Item which do not
appear in a post (e.g. a wiki page may contain an attachment which is
not linked to from a page).
> The embeds property could allow files to be viewed (e.g. remote video
> files) or embedded metadata to be incorporated (e.g. in some structured
> / semantic blog posts, so that embeds -> object with metadata) in a
> post. There may be a distinction between something that is attached and
> something that is embedded - the former may not be displayed in the post
> whereas the latter is - and something that is attached may also be embedded.
>
> Another alternative is to use something instead of attachment / embeds
> that can be used interchangeably, e.g. includes or contains (although
> the latter confuses with sioc:has_container). This would remove
> ambiguity over which to use (if someone won't use both).
Existing properties: attachment, links_to
Needed: a property that points to things that a post/item contains.
Suggestions: embeds, contains, or any new suggestion.
c) "Things" and concepts that a post/item is about
We want to tell what [things or concepts] a post or item is about.
John did not mention this kind of relations directly but there is a
thin line between the things a post/item is about and things contained
within a post/item. Existing properties: sioc:topic to point to
category and tag URIs (with an rdfs:label to add a text label);
dc:subject to express plain text keywords.
Currently SIOC expresses categories and tags, but does not tell how to
say that this is "a post about film F1" or "a post about presentation
P1 by person X". We need a way to do this.
Option: Use a sioc:topic pointing to [the URI of] the object a
post/item is about. This is a generic way how to describe relation to
any kind of an object. Type / class of the object can then specify
what kind of an object this is.
> Myself and Uldis have been wracking our heads trying to come up with the
> best way to do this, so it'd be good to have your ideas on this.
Please add your comments / suggestions.
All are welcome. :)
Best,
Uldis
capt...@gmail.com
We (SIOC development community) are looking forward to your
suggestions on how to connect blog posts (expressed as sioc:Posts)
with different types of data / content that these posts contain or are
about. All comments are welcome.
Copying this to FOAF-Dev and DOAP-Interest lists because software
projects in DOAP can be one of the things people want to talk about.
And FOAF is already integrated in RDF data exported by SIOC enabled
forums and weblog, which means that developments in one can also help
the other.
You will a detailed description of this question at the original
SIOC-Dev discussion thread [1] and in the last (summary) message from
it which can be found below.
[1] http://groups.google.com/group/sioc-dev/browse_thread/thread/a443ae44fc9b0441
Best,
Uldis
Benja Fallenstein
2007/3/9, capt...@gmail.com <capt...@gmail.com>:
> b) "Things" contained within / linked to from a Post/Item
>
> A Post/Item may contain or link to objects which we may want to tell
> more about. Things contained within a post can be an Image, or a
> Review.
We talked about this on IRC and I suggested
* that the property could be has_piece, because we already have
sioc:contains and sioc:has_part (both with unrelated meanings)
* that we could use awol:Content as the type of attachments, e.g.
post sioc:has_piece [ a awol:Content; awol:src <foo1823.jpg> ].
The spec of awol:Content is here:
http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#Content
===
Content Class - see §4.1.3 in rfc 4287 One way to think of this is as
a class that represents what one can get from an HTTP connection. It
has a body, and a number of headers, info such as mime-type,
content-lenght, etc... .
===
So an instance of awol:Content doesn't need to be the content of
anything, even though Atom/OWL does use it for the content of feeds,
and using it for attachments doesn't conflict with using it for the
main content of a post. The reason I'm suggesting it is that it would
allow us to use the same RDF structure for including attachments in
the RDF (through awol:body) and referring to them externally (through
awol:src).
> c) "Things" and concepts that a post/item is about
>
> We want to tell what [things or concepts] a post or item is about.
>
> John did not mention this kind of relations directly but there is a
> thin line between the things a post/item is about and things contained
> within a post/item. Existing properties: sioc:topic to point to
> category and tag URIs (with an rdfs:label to add a text label);
> dc:subject to express plain text keywords.
>
> Currently SIOC expresses categories and tags, but does not tell how to
> say that this is "a post about film F1" or "a post about presentation
> P1 by person X". We need a way to do this.
I'd suggest using foaf:topic.
http://xmlns.com/foaf/0.1/#term_topic
===
The foaf:topic property relates a document to a thing that the
document is about.
As such it is an inverse of the foaf:page property, which relates a
thing to a document about that thing.
===
- Benja
Alexandre Passant
On 3/13/07, Benja Fallenstein <benja.fa...@gmail.com> wrote:
>
> > c) "Things" and concepts that a post/item is about
> >
> > We want to tell what [things or concepts] a post or item is about.
> >
> > John did not mention this kind of relations directly but there is a
> > thin line between the things a post/item is about and things contained
> > within a post/item. Existing properties: sioc:topic to point to
> > category and tag URIs (with an rdfs:label to add a text label);
> > dc:subject to express plain text keywords.
> >
> > Currently SIOC expresses categories and tags, but does not tell how to
> > say that this is "a post about film F1" or "a post about presentation
> > P1 by person X". We need a way to do this.
>
> I'd suggest using foaf:topic.
>
> http://xmlns.com/foaf/0.1/#term_topic
> ===
> The foaf:topic property relates a document to a thing that the
> document is about.
>
> As such it is an inverse of the foaf:page property, which relates a
> thing to a document about that thing.
> ===
Currently, I use sioc:topic to link a post to any rdf:Resource (while
keeping dc:subject for the original "tag", as Uldis mentionned)
eg (in my post):
<http://foobar> a sioc:Post .
<http://foobar> sioc:topic <http://movie1> .
and (in another RDF document where I defined the movie)
<http://movie1> a xxx:Movie
[...]
But, actually, I've never realized the overlap between foaf:topic and
sioc:topic ... but seems they're the same ? Maybe we should re-use
foaf:topic (would be OK since a sioc:Post subclassOf foaf:Document)
directly, or at least make it a subproperty of foaf:topic
Alex.
> - Benja
>
> >
>
john.b...@deri.org
> sioc:topic ... but seems they're the same ? Maybe we should re-use
> foaf:topic (would be OK since a sioc:Post subclassOf foaf:Document)
> directly, or at least make it a subproperty of foaf:topic
I think the problem with reusing foaf:topic was that we wanted to use
sioc:topic to talk about topics linked to a User, Site, etc. which
aren't foaf:Documents (although sioc:Post is subclassed)...
Benja Fallenstein
2007/3/13, Alexandre Passant <al...@passant.org>:
> Currently, I use sioc:topic to link a post to any rdf:Resource (while
> keeping dc:subject for the original "tag", as Uldis mentionned)
>
> But, actually, I've never realized the overlap between foaf:topic and
> sioc:topic ... but seems they're the same ?
Actually, sioc:topic is different in the specification, and foaf:topic
seems to be what you want. Or is that one of the things that you guys
were planning to change? The current SIOC specification has the
following example:
:post\_123
a sioc:Post ;
sioc:topic <http://dmoz.org/Business/Publishing\_and\_Printing/> .
The intent would appear to be to express that :post\_123 is about
publishing and printing, *not* that it is about the *page*
<http://dmoz.org/Business/Publishing\_and\_Printing/> (which would be
the meaning if we used foaf:topic instead of sioc:topic).
http://rdfs.org/sioc/spec/#term_topic
I think we should use the FOAF property if we want its semantics:
duplicating it as a SIOC property doesn't strike me as useful...
- Benja
Uldis Bojars
> > b) "Things" contained within / linked to from a Post/Item
> >
> > A Post/Item may contain or link to objects which we may want to tell
> > more about. Things contained within a post can be an Image, or a
> > Review.
>
> We talked about this on IRC and I suggested
>
> * that the property could be has_piece, because we already have
> sioc:contains and sioc:has_part (both with unrelated meanings)
> * that we could use awol:Content as the type of attachments, e.g.
>
> post sioc:has_piece [ a awol:Content; awol:src <foo1823.jpg> ].
- sioc:has_piece sounds ok (though "piece" may mean a "gun" to some)
- we can also reuse sioc:has_part if we subclass sioc:Community from
a container (and from has_part from it)
- sioc:contains is another option, but bad because there's already
sioc:content.
Thoughts about the sioc:embeds - it (and also sioc:attachment) is more
specific than sioc:contains / has_part / has_piece. Therefore a need
for a generic property discussed here, with sioc:embeds and
sioc:attachment being special cases (subproperties) of it.
About hierarchies of new classes and properties:
We see an "explosion" of subtypes for sioc:Post / sioc:Item. When we
add some new subtypes of Post there appears a need for even more.
E.g., just added MailMessage and InstantMessage, but Tukkah on #sioc
is exporting IRC logs in SIOC (as sioc:Post for now).
Questions:
- Do we also need a sioc:IrcMessage then?
- Private messages in IRC? - are those IrcMessage(s) or InstantMessage(s).
- How are sioc:MailMessage and sioc:InstantMessage different?
Could someone working on expressing e-mail, instant and Usenet
messages in SIOC tell his thoughts about this?
If we need new classes and properties we should add those. But we
should also look at the new additions and see maybe we need to
refactor these changes - e.g., if two of the new classes are
essentially the same.
>
> The spec of awol:Content is here:
>
> http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html#Content
> ===
> Content Class - see §4.1.3 in rfc 4287 One way to think of this is as
> a class that represents what one can get from an HTTP connection. It
> has a body, and a number of headers, info such as mime-type,
> content-lenght, etc... .
> ===
>
> So an instance of awol:Content doesn't need to be the content of
> anything, even though Atom/OWL does use it for the content of feeds,
> and using it for attachments doesn't conflict with using it for the
> main content of a post. The reason I'm suggesting it is that it would
> allow us to use the same RDF structure for including attachments in
> the RDF (through awol:body) and referring to them externally (through
> awol:src).
awol:Content is very generic, that's nice. We can use both awol:body
for literal content and awol:src for content that is located
elsewhere. Interesting, have to see how it is used. This does not mean
awol:Content has to be used for all kinds of content, but it is a good
candidate for some.
You have shown an example of using it with has_piece, but it suits
even better when talking about different representations of a message.
We also need a property to connect a Post / Item to a representation
of its body. sioc:body (sioc:has_body) and sioc:content_enhanced were
mentioned. Out of these two I'd prefer sioc:has_body.
While content_enhanced was the best option we could think during the
meeting, body of the message is actually not enhanced, the opposite is
true - sioc:content is a stripped-down plain text content and
sioc:<new property name> is a normal content, possibly in different
representations.
One more option is to use sioc:content for both (a) literal plain-text
content and (b) for real resources, e.g., of type awol:Content.
Question: is it a good idea to mix both types of content in the same property?
There was also a suggestion (by Kingsley?) to introduce
sioc:text_content (or similar) property and use it for what is
sioc:content now, leaving sioc:content for the real resources. But how
does this influence existing implementations and users of SIOC data?
We don't want to break what is already being used.
Uldis
Uldis Bojars
Thanks. That's why we have sioc:topic. Additional benefit is that we
can explain the use of sioc:topic within the SIOC ontology and
specification, or change it when revisions are needed.
Benja is right, sioc:topic is one the properties which we can use and
should change.
We can continue to use sioc:topic for tags, categories and
skos:Concepts. And since it can be any URI we can also use it to point
to the resources a Post / Item is about (maybe with some changes to
its rdfs:comment).
When we do that we will need a way to distinguish between different
kinds of topics - what are tags, what are categories and what are the
_things_ a post is about. Solution: to use the rdf:type of the URI
which sioc:topic points to determine what it is. E.g.:
post_1 sioc:topic resource_A .
resource_A a skos:Project .
To distinguish when a topic points to a category or tag new types of
topics can be added to types module. E.g.:
post_1 sioc:topic topic_SW .
topic_SW a sioct:Category .
This is a generic model how to express what a post is about, building
on the sioc:topic we are already using.
It can be tempting to use both sioc:topic and foaf:topic. John
outlines one of the reasons why it is not done. Another thing - it can
very confusing if both are used. Best we can do is learn from FOAF and
change / improve sioc:topic as needed.
Finally finished writing all about changes needed. Time to go to sleep. :)
Uldis
Uldis Bojars
let's separate every issue to a thread of its own.
Will post the issues to the list shortly.
Uldis