AtomOWL usage within SIOC
Christoph Görn
I have shortly noted down why and how we may use AtomOWL's Content
class to represent a sioc:Post's contetn in a more rich way. Please
read on at http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-
atomowl-a-new-way-to-describe-content/
Christoph aka [GNU]
--
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?
Danny Ayers
> Hello all,
> I have shortly noted down why and how we may use AtomOWL's Content
> class to represent a sioc:Post's contetn in a more rich way. Please
> read on at http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-
> atomowl-a-new-way-to-describe-content/
I'm a bit biased having been involved in the AtomOWL stuff, but I do
think this is a good idea.
There are benefits in flexibility (potentially any content type can be
included), modelling (more info about the content) and processibility
(tools can interpret e.g. XHTML content directly).
'Course you could get those benefits by making up new terms. But I
reckon the specific tie to Atom is likely to be useful. There's going
to be an increasing amount of Atom data around and lot of Atom
Protocol-capable services. So being able to hook fairly directly into
Atom's content model should provide a lot of SemWeb-friendly
data/services at low cost (which incidentally is what got me
interested in AtomOWL).
Another reference point re. moving away from content:encoded, the RSS
1.0 feed for Planet RDF (and presumably all the other
Chumpalogica-based Planets) has for a long while used this:
<planet:content xmlns="http://www.w3.org/1999/xhtml" rdf:parseType="Literal">
<div>
// XHTML fragment
</div>
</planet:content>
http://planetrdf.com/index.rdf
Cheers,
Danny.
--
Henry Story
> Hello all,
> I have shortly noted down why and how we may use AtomOWL's Content
> class to represent a sioc:Post's contetn in a more rich way. Please
> read on at http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-
> atomowl-a-new-way-to-describe-content/
>
> Christoph aka [GNU]
> --
> Christoph Görn <go...@B4mad.Net>
> http://B4mad.Net/FOAF/goern.rdf#goern
Thanks for working on this Christoph. This is very helpful. It
already helps me understand sioc better :-) It also does make it more
urgent that we should start working on getting something close to a
permanent home for AtomOwl.
AtomOwl is trying to provide a semantics for atom, that can then be
used to SPARQL query atom servers, in a way that is easily understood
by atom xml people. As such I am mostly focused on looking at Atom.
But it will very much help to have other people pulling in other
directions. There are different ways of mapping Atom to rdf, so that
seeing how the ontology could fit into other project may help us make
some decisions that we find difficult to make alone.
Looking more carefully at your sioc
<sioc:Post xmlns="http://bblfish.net/work/atom-owl/2006-06-06/#"
xmlns:sioc="http://rdfs.org/sioc/"
xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
rdf:about="http://B4ma...cribe-content/">
<sioc:link rdf:resource="http://B4ma...cribe-content/"/>
<sioc:has_container rdf:resource="http://b4ma...hp?
sioc_type=site#weblog"/>
<sioc:title>SIOC and AtomOWL: a new way to describe content…</
sioc:title>
<sioc:has_creator rdfs:label="gnu" rdf:resource="http://
B4ma...uthor/gnu/"/>
<sioc:created_at>2006-08-21T17:49:06Z</sioc:created_at>
<content rdf:parseType="Resource">
<body rdf:parseType="Resource">
<xhtml><div xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
xml:base="http:/b4mad.net/">
<p><i>[content of the post itself here]</i></p>
</div></xhtml>
</body>
<type>text/xhtml</type>
</content>
<sioc:topic rdfs:label="sioc" rdf:resource="http://B4ma…tic-web/
sioc/"/>
<sioc:has_reply>
<sioc:Post rdf:about="http://B4ma…cribe-content/#comment-20558">
<rdfs:seeAlso rdf:resource="http://b4ma…ment&sioc_id=20558"/>
</sioc:Post>
</sioc:has_reply>
</sioc:Post>
I notice that there are some other points of overlap between atom and
sioc.
atom has title, topic, created relations too.
Now title, subtitle and summary are all relations to :TextContent
objects, because in atom one needs to distinguish between plain text
content, html content, and xhtml content. (That's what the atom folks
wanted!) This helps explain why atom owl may be a little more
complicated than one would otherwise want. But then again it will
better map to the data that one finds without loss.
Another thing that is worth noting, is that the way things are moving
in the atom community is via people sending rfcs for adoption on atom
extensions. I am going to have to see how I can integrate these into
atomOwl. We should keep track of these extensions. It would be nice
if in the future extensions would also come with semantics for how
they should map to atom owl... But for that to happen we will
certainly need to have an acknowledged formal home.
In any case there are some rfc being talked about for extending atom
with features such as tracking replies of documents... Perhaps we
should put up a wiki page for tracking these rfcs.
Henry
Home page: http://bblfish.net/
Sun Blog: http://blogs.sun.com/bblfish/
Foaf name: http://bblfish.net/people/henry/card#me
Benja Fallenstein
For people like me who prefer to think in Turtle rather than RDF/XML,
the triples look like this:
_:post rdf:type sioc:Post.
_:post atom:content [ atom:type "xhtml"; atom:body "<p>Foo</p>" ].
Alternatively, Atom/OWL permits
_:post atom:content [ atom:xhtml "<p>Foo</p>" ].
If SIOC adopts this, this raises the question whether to use the same
method for titles, which after all in real systems can contain HTML,
too.
- Benja
Henry Story
> Hi all,
>
> For people like me who prefer to think in Turtle rather than RDF/XML,
> the triples look like this:
>
> _:post rdf:type sioc:Post.
> _:post atom:content [ atom:type "xhtml"; atom:body "<p>Foo</p>" ].
>
> Alternatively, Atom/OWL permits
>
> _:post atom:content [ atom:xhtml "<p>Foo</p>" ].
which in N3 can also become
_:post atom:content "<p>Foo</p>"^atom:xhtml .
(note the single ^ which is very reminiscent of the ^^ of literal
typing, and purposefully so according to timbl)
:-)
Benja Fallenstein
> which in N3 can also become
>
> _:post atom:content "<p>Foo</p>"^atom:xhtml .
>
> (note the single ^ which is very reminiscent of the ^^ of literal
> typing, and purposefully so according to timbl)
>
> :-)
And hard to figure out for the uninitiated like me :-(
- Benja
Uldis Bojars
Christoph Görn wrote:
> Hello all,
> I have shortly noted down why and how we may use AtomOWL's Content
> class to represent a sioc:Post's contetn in a more rich way. Please
> read on at http://b4mad.net/datenbrei/archives/2006/08/21/sioc-and-
> atomowl-a-new-way-to-describe-content/
It is nice to see an example how SIOC and AtomOWL can be combined
together. Using AtomOWL to express the content of a post is a better
idea than using content:encoded and CDATA from RSS1.0, no doubt there.
Note: in your example - did you intend to use a aowl:content property
to link a sioc:Post and aowl:Content?
It is probably more logical for a property linking them to be part of
SIOC - so that we know there is one property in SIOC that can be used
to link posts to their content (regardless of the ontology used to
represent the content itself).
There already is a sioc:content property [1]. It was intended to
contain a text representation of the content (while content:encoded
would contain the "rich" content) and its range currently is
rdfs:Literal.
Could it be possible to use this property both for text only content
(if aowl:Content is not provided) and for richer content as in this
example?
[1] http://rdfs.org/sioc/spec/#term_content
Uldis
Uldis Bojars
Uldis Bojars wrote:
> There already is a sioc:content property [1]. It was intended to
> contain a text representation of the content (while content:encoded
> would contain the "rich" content) and its range currently is
> rdfs:Literal.
>
> Could it be possible to use this property both for text only content
> (if aowl:Content is not provided) and for richer content as in this
> example?
Using a sioc:content for dual purpose - to allow both a literal and an
object (URI or blank node) value is not a good practice. DC has some
properties like that but it won't be much good if a data consumer can't
know what type of data to expect.
I propose to link SIOC to AtomOWL (and other kinds of objects that can
describe post body content) by adding a new property - sioc:body.
It would have rdfs:domain = sioc:Post and no range contraints, leaving
it possible to use any kind of suitable ontology to describe contents
of a post.
This proposal serves two purposes:
- give some predictability to applications that will know how to find
post body
- allow flexibility in what ontology (AtomOWL, ...) to use
Why flexibility is valuable? There can appear other ontologies that are
better suited for, e.g., describing wiki content - then you can use
this ontology without changes to SIOC specification and ontology. If
later on we decide we need to limit the range of this property, that
can be done very easily - by adding rdfs:range or subclassing from
aowl:content.
Currently this property will be used with AtomOWL - once we know how to
link them (SIOC and AtomOWL) we can describe that in the specification
and do actual implementations.
P.S. Why I used wiki as an example is because while AtomOWL is very
good and allows to specify MIME type of the content this does not help
too much for wiki markup - there are a number of different wiki markups
and no MIME type for any of them.
P.P.S. In no way is this to suggest that AtomOWL is bad or should not
be used - quite the contrary! :)
Uldis