Comments on: Unhappy with sioc:content http://www.clauwa.info/2009/02/19/unhappy-with-sioccontent/ Claudia Wagner :: Weblog Wed, 22 May 2013 15:21:16 +0000 http://wordpress.org/?v=2.6.2 By: Claudia Wagner http://www.clauwa.info/2009/02/19/unhappy-with-sioccontent/#comment-389 Claudia Wagner Sun, 08 Mar 2009 12:11:33 +0000 http://www.clauwa.info/?p=267#comment-389 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... 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…

]]> By: peter http://www.clauwa.info/2009/02/19/unhappy-with-sioccontent/#comment-382 peter Thu, 19 Feb 2009 20:29:20 +0000 http://www.clauwa.info/?p=267#comment-382 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. 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.

]]> By: clauwa http://www.clauwa.info/2009/02/19/unhappy-with-sioccontent/#comment-379 clauwa Thu, 19 Feb 2009 19:05:57 +0000 http://www.clauwa.info/?p=267#comment-379 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. 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.

]]> By: Simon Reinhardt http://www.clauwa.info/2009/02/19/unhappy-with-sioccontent/#comment-378 Simon Reinhardt Thu, 19 Feb 2009 17:04:27 +0000 http://www.clauwa.info/?p=267#comment-378 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. 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.

]]>