We can do the SIOC property change that Kingley proposes provided that
awol:Content remains in the AtomOWL ontology. :Content is a well
designed class and can be more flexible than just a bunch of :html,
:xhtml, :...

Proposed actions (if we proceed):
- rename existing sioc:content to sioc:text
- instroduce a new property sioc:content that'll link to an object =
content of a post
- describe linking of SIOC and AtomOWL in
http://esw.w3.org/topic/SIOC/RelatedOntologies + add examples

This new property will be used to link a sioc:Post to an object
representing its content / body. Its domain will be sioc:Post; no
range restriction (main intended use is to link to awol:Content, but
other ontologies could also be used to represent content).

What do you think?

Uldis

[ http://captsolo.net/info/ ]

On 10/26/06, kidehen wrote:
>
> Anyway, for those who haven't picked up my reply. The suggestion I am
> making if that ":Content" should remain unchanged. It already handles
> the definition of what is populary known as "Web Content" effectively
> :-)
>
> Kingsley
>
> On Oct 25, 9:29 am, Henry Story wrote:
> > Mhh... I tried removing the :Content again, but then remembered why I
> > had not done that before (or one of the reasons).
> >
> > atom specifies that the 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
> >
> > On 23 Oct 2006, at 21:21, Henry Story wrote:
> >
> > > On 23 Oct 2006, at 19:35, kidehen wrote:
> > >> A continuation of the discussion from
> > >> > > >> 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 Run Amok"^^:html;
> > > :link [ :href
> > > :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
> > > :rel iana:content;
> > > :type "text/html";
> > > ] .
> >
> > > could be equivalent to
> >
> > > [] a :Entry;
> > > :title "Atom-Powered Robots Run Amok"^^:html;
> > > iana:alternate [ a :Content;
> > > :type "text/html";
> > > :src ];
> > > :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
> > > :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
> > > iana:content [ a :Content;
> > > :src ;
> > > :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 [ =
> > > :representation [ :type "text/html" ]
> > > ];
> > > :id "urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a"^^xsd:anyURI;
> > > :updated "2003-12-13T18:30:02Z"^^xsd:dateTime;
> > > iana:content [ = ;
> > > :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 Run Amok"^^:html;
> > > iana:alternate [ =
> > > :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 [ = ;
> > > :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
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "SIOC-Dev" group.
To post to this group, send email to sioc-dev@googlegroups.com
To unsubscribe from this group, send email to sioc-dev-unsubscribe@googlegroups.com
For more options, visit this group at http://groups.google.com/group/sioc-dev
-~----------~----~----~----~------~----~------~--~---