Re: Contd: AtomOWL and SIOC Integration
Henry Story
On 23 Oct 2006, at 19:35, kidehen wrote:
> A continuation of the discussion from
> <http://groups.google.com/group/sioc-dev/browse_thread/thread/
> 17b46d33cdf45f8/>:
>
> Atom is clearly a more detailed specification for Web Content and its
> wide adoption is inevitable (IMHO). Thus, I would like to suggest that
> we consider a term change re. sioc:content since it currently
> refers to
> the Text Content of a "Post" rather than the actual Content of a
> "Post"
> which AtomOWL covers very well. My replacement term suggestions are
> any
> of the following:
> sioc:text
> sioc:plain_text
>
> I think we have a great opportunity to connect SIOC and AtomOWL via
> sioc:content especially as SIOC is very much in its early days.
Hi, thanks for the comments.
A little problem: I have been thinking of removing the awol:Content
class from AtomOwl and replacing it with Literals in the thread
"Making Content into Literals in AtomOwl" [1]
It removes one level of indirection in the relation between an entry
and a feed and its title value, and so is closer to the atom syntax,
which may make it easier to query using a SPARQL end point such as
the one I put up recently [2]. I mention further advantages in that
thread. It does mean that I do have to create a number of new literal
types awol:html and awol:xml .
It may well be that there was a good reason for not doing this .
Could you give a quick example of how you were thinking of using
awol:Content ?
Any other feedback would be appreciated.
There may be a way of re-introducing it though, whilst keeping the
benefits of the simpler literal notation.
This would be to make the link relations types be relations between
an entry/feed and a :Content
[] a :Entry;
:title "Atom-Powered Robots <b>Run</b> Amok"^^:html;
:link [ :href <http://example.org/2003/12/13/atom03>
:rel iana:self;
:type "application/atom+xml" ];
:id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
:link [ :href <http://eg.com/src.html>
:rel iana:content;
:type "text/html";
] .
could be equivalent to
[] a :Entry;
:title "Atom-Powered Robots <b>Run</b> Amok"^^:html;
iana:alternate [ a :Content;
:type "text/html";
:src <http://example.org/2003/12/13/atom03> ];
:id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
iana:content [ a :Content;
:src <http://eg.com/src.html>;
:type "text/html" ] .
if we add the N3 rule
{ ?x :link [ :rel ?relation;
:type ?type;
:href ?href ] . } => { ?x ?relation [ :src ?href;
:type ?
type ] . } .
Which is kind of why I was thinking of calling this ontology Atom N3.
This seems to explain very clearly the meaning of the link relation.
The other way I had thought of doing this, discussed a long way ago,
and closer to the W3C Architecture document, would have been to use
the following rule:
{ ?x :link [ :rel ?relation;
:type ?type;
:href ?href ] . } => { ?x ?relation ?href.
?href :representation
[ :type ?type ] . } .
[] a :Entry;
:title "Atom-Powered Robots Run Amok"^^:text;
iana:alternate [ = <http://example.org/2003/12/13/atom03>
:representation [ :type "text/html" ]
];
:id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
iana:content [ = <http://eg.com/src.html>;
:representation [ :type "text/html" ]
].
At the time when I discussed this with Reto in Bern [3] we had gone
against this idea because we thought that if we mashed up two atom
feeds we would end up perhaps with something like
[] a :Entry;
:title "Atom-Powered Robots <b>Run</b> Amok"^^:html;
iana:alternate [ = <http://example.org/2003/12/13/atom03>
:representation [ :type "text/html" ]
:representation [ :type "application/atom+xml" ]
];
:id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
:updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
iana:content [ = <http://eg.com/src.html>;
:representation [ :type "text/html" ]
].
And well this may or may not be a correct reading of the atom xml.
At the time though, I was not familiar with graphs, and if we keep
our data separated by graphs in our database, we should always be
able to reconstitute what a particular feed said by looking at the
triples generated by the graph.
These questions have been driving me crazy... ;-)
Henry
[1] http://groups-beta.google.com/group/atom-owl/browse_thread/thread/
6eaaf3705d23747
[2] http://roller.blogdns.net:2020/snorql/
[3] http://blogs.sun.com/bblfish/entry/splitting_the_atom_in_bern
Axel Polleres
SIOC related ontologies document on the wiki?
http://esw.w3.org/topic/SIOC/RelatedOntologies
I think this would be helpful
--
Dr. Axel Polleres
email: ax...@polleres.net url: http://www.polleres.net/
Henry Story
had not done that before (or one of the reasons).
atom specifies that the <content> element can contain
atomInlineOtherContent =
element atom:content {
atomCommonAttributes,
attribute type { atomMediaType }?,
(text|anyElement)*
}
to do this with literals, I would have to create a huge number of
different literal types, one for each different media type. Now I am
not sure if this would be a bad idea or not.
Could one think of media types as literal specifications? Would this
make sense:
"...."^^iana_image:jpg
?
Perhaps the awol:Content is really not such a bad idea. What it
enables is one to refer to representations indirectly via urls, it is
very flexible, close to web arch, and there is a easy relation with
literals to be made at some point
x :content "b"^^:xhtml .
is afer all very close to
x :content "b"^:xhtml .
Sorry. I sometimes forget all the reasons for why I ended up with the
current AtomOwl.
Henry
kidehen
I believe your goal here is to provide a granular mechanism for
exposing the constituent parts of what is populary known as "Web
Content". You already address matters that cover the shapes and forms
of "Web Content" in the current ":Content" definition. I believe you
should leave this unchanged in its current form, especially as this is
what presented the obvious synergy with SIOC. The hope is that the
":Content" class in either Ontology means the same thing. Achieving
this will me a win-win (IMHO).
Kingsley