Unhappy with sioc:content
Author: Claudia Wagner | Published: 19th February 2009 | RSS | LINK
Somehow I have some problems with the sioc:content property, because the fact that it is limited on plain text seems to limit me as well 
I wonder how I should model for example a blog post which consists only (or mainly) of images? I can describe each image itself with foaf or exif ontology, ok. But how do I express that these images are the content of the post? sioc:embeds would be a possibility and I am using it at the moment in my extended SIOC WP exporter.
But why am I not happy with this solution?
First I have no possibility to model relations between different content items (text blocks, images, videos) and positional information (which I might need to serialize the RDF model of a post in XHTML/RDFa - seeAlso posting from Uldis) get lost during exporting a post in RDF. The triples of a post only expose that some multimedia content and some unstructured text is contained in the post. If we are looking at the HTML representation of a post, we get a richer picture. We have sections, text belonging to images and so on…
I suggest to change the range of the sioc:content property from rdfs:Literal to rdfs:Resource (or sioc:Item). This would allow to model the content of sioc:Items on a higher granularity level. For example the relations (positional relations such as sioc:next, sioc:before and argumentative relations such as sioc:arises_from, sioc:agrees_with ) between individual content items could so be exposed as well.
My second point is that the name sioc:content seems to be confusing to me. A sioc:Item can be everything stored in a sioc:Container and the sioc type module introduces container such as ImageGallery, Video Channel and so on. I wonder if a property sioc:content, which can only holds plain text, can ever expose the content of the items stored in this containers?
Maybe it would be better to rename the current sioc:content property (which has a rdfs:Literal as range) to sioc:text_content or sioc:text and have another property sioc:content which has as range rdfs:Resource.
In the end I would like to be able to express something like this:
4 Comments. Add yours!
Leave a Reply
Some basic HTML is allowed. Please keep all comments constructive, polite and on-topic. Any spam or offensive comments will be deleted.
I’m fine with its range. sioc:content is one way of describing the contents and there are many other possible ones. If you need others you could propose more properties but I don’t think sioc:content itself should be changed since it’s one deployed solution. Yes, it doesn’t cover every case, e.g. what’s the literal content of an image. But remember that you don’t *have* to use this property, it’s just one option.
The name may not be ideal but that’s just a label, the definition says what it’s about.
If you want to describe the content in a more structured way use XHTML, that’s what it’s for. No need to reinvent the wheel with SIOC properties here.
You can use it to define text blocks, you can use it to include images - and you would normally just reference those instead of embedding them inline. So the images themselves are not the content of the post but the references to them are. Unless you actually just post an image.
I’m not sure we would agree what a sioc:Item or sioc:Post actually is. To me it’s not a meta-object but the object itself. So an image or the blog post page are all sioc:Items. You don’t need an extra sioc:Item that refers to them for the content.
I don’t think you need to export the whole content of the post in all its richness in RDF. Rather what you export is the metadata about it. The HTML page itself *is* the post so if someone wants to actually read it they just need to dereference the URI of the sioc:Post. This is the easiest way because it gives you most flexibility over what the content actually is - the server will tell the client about the MIME type and the client can figure out how to parse and render it and everything.
But if you want to transfer it anyway for aggregation purposes or whatever then you could just plainly serialise it into a literal (or an rdf:XMLLiteral) and add a property to the sioc:Post/sioc:Item for describing its MIME type, dcterms:format or something to that effect.
Simon,
I may be wrong, but I thought (or I am still thinking) that a sioc:Item or sioc:Post can be both a object or metaobject. The content of a sioc:Post or sioc:Item consists of plain text and/or references to other objects, right? In the case a sioc:Item only holds references to other objects, it seems to be a metaobject, or?
“The HTML page itself *is* the post”, but a post can consists of different entities/sections, which may have e.g. different properties (e.g. different origins, authors, positions). If I dont’t identify individual content entities/section I cannot reference them and cannot talk about them.
Changing a deployed solution, might not be the best idea, I agree. But the label sioc:content didn’t let me expect that we are talking about plain text only, especially not because the property can be used for all sioc:Items.
What about creating and using something like that:
Property: sioc_ext:detailed_content
OWL Type: ObjectProperty
Domain: sioc:Item
Range: sioc_ext:Your_Fine_Grained_Content_Container
With:
sioc_ext being your extension to the SIOC vocabulary.
Your_Fine_Grained_Content_Container being a content container of your needs.
detailed_content being a property for non plain text content.
I just stumpled across this discussion from 2006:
http://groups.google.com/group/atom-owl/browse_thread/thread/b8f03fb9bd0983e2/c27bc45e680df0df
Maybe using the AtomOWL Content class is a good solution without needing to change/rename the sioc:content property.
As described here (http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-atomowl-a-new-way-to-describe-content/) awol:content can be nicely combined with SIOC.
From my point of view advantages of using awol:Content are that additional information about the content (e.g. language, type) can be exposed and that relations (e.g. refers_to, next) between individual instances of the Content class could be modeled. I also like the awol:src property of the awol:Content class, which allows to express that the representation of an external object is part of the content.
However, what I have learnt from this is that it is not that easy to decide which vocabularies to use…