RE: Structured Publishing -- Joe Reger shows the way...

[Bob Wyman]

Eric Scheid wrote:
> The article goes into content as text/xhtml, and the RDF goes
> into the  as extensions.
Every Atom entry is supposed to have an alternate HTML
representation or be an alternate representation of some HTML. Given that,
then where would one find the RDF in the HTML representation of the entry?
I believe it doesn't make sense for us to add data-carrying elements
to Atom other than atom:content or atom:summary. Atom provides a definition
of a collection of entries and it provides the entry format. Frankly, it
should stop there. The data payload should be carried in the content
element.
This is the approach we take with "Stuctured Blogging"[1]. The idea
is that you insert the machine parseable data into the content element and
you also insert it into the body of the HTML that is an alternate of the
atom:entry. Thus, the machine readable data can be found either by reading
the feed or by reading the HTML pages that are alternates of the entries in
the feed. One of the very nice things about this approach is that it enables
data to be carried in HTML, XHTML, RSS, and Atom with complete consistency
and without having to define extensions to any of the formats. Additionally,
because Structured Blogging relies on normal XML, it means that the same
data that you embed in HTML, XHTML, RSS and Atom can also be processed
without modification by normal and widely available XML parsers, tools, etc.
By providing GRDDL transformations for Structured Blogging entries, we also
gain the benefit of being able to directly address the needs of the
RDF/OWL-semantic processing crowd. All this can be done without defining new
extension elements, without having to coordinate between extensions in RSS
and Atom and without breaking any rules of HTML and/or XHTML. 
Data should be in the content element...

Bob wyman

[1] http://structuredblogging.org

Re: Structured Publishing -- Joe Reger shows the way...

[Eric Scheid]

On 12/9/05 9:00 AM, "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:

> * Henry Story <[EMAIL PROTECTED]> [2005-09-12 00:05]:
>> In the DOAP over Atom type solution where the RDF is placed
>> inside the content, there  is then no more space to put the
>> entry content itself. So I can either put  the text entry into
>> the content or the metadata. Where should the metadata go?
> 
> Hmm. I think it¹s not metadata that we¹re talking about here,
> it¹s data. The location etc aren¹t a description of your weblog
> entry, they¹re a description of a place. So is your article.
> 
> In other words, your article is ³meta²data about the cool bar.
> So it goes inside the RDF that is the entry¹s content.

I was thinking the opposite. The article goes into content as text/xhtml,
and the RDF goes into the  as extensions.

> Now, that¹s not going to be accessible to clients who don¹t know
> look in the right place in the graph.

Again, all the RDF extensions won't be accessible to clients that don't know
where to look, but the article content will be available, because it's one
of the baseline formats.

> So you put a copy of the article in your atom:summary, because it
> summarizes the full thing available in the RDF payload.

Not if it's a long article, please.

e.

Re: Structured Publishing -- Joe Reger shows the way...

[James M Snell]

Henry Story wrote:

Is  DOAP over Atom [1] an example of the type of solution you are  
suggesting James?


This is exactly what I'm talking about. 

That looks good. But what if I want to annotate an entry with some  RDF? 


The question is: is the metadata you're wishing to add descriptive of 
the entry or descriptive of whatever it is you're talking about in the 
entry?  If it's the former, add the namespaced elements directly to the 
atom:entry and use something like GRDDL to extract the information you 
need during processing.  If it's the later, what you're really talking 
about is content that belongs in the content element.


- James

Re: Feed History -04

[James Holderness]

I also have a question regarding the fh:incremental element. While the spec 
says it SHOULD occur, and it MAY be assumed "true" if the document contains 
a fh:prev element, it doesn't say how to interpret a document which has 
neither fh:incremental nor fh:prev (which is exactly the status of most 
feeds in existence). The most obvious interpretation would be to assume an 
fh:incremental value of "true", but if that's the case why bring up the 
issue of whether the fh:prev element is present or not?


On an unrelated note, shouldn't the default namespace in the atom examples 
be "http://www.w3.org/2005/Atom";?

Re: Structured Publishing -- Joe Reger shows the way...

[A. Pagaltzis]

* Henry Story <[EMAIL PROTECTED]> [2005-09-12 00:05]:
> In the DOAP over Atom type solution where the RDF is placed
> inside the content, there  is then no more space to put the
> entry content itself. So I can either put  the text entry into
> the content or the metadata. Where should the metadata go?

Hmm. I think it’s not metadata that we’re talking about here,
it’s data. The location etc aren’t a description of your weblog
entry, they’re a description of a place. So is your article.

In other words, your article is “meta”data about the cool bar.

So it goes inside the RDF that is the entry’s content.

Now, that’s not going to be accessible to clients who don’t know
look in the right place in the graph.

So you put a copy of the article in your atom:summary, because it
summarizes the full thing available in the RDF payload.

Does that sound about right?

Regards,
-- 
Aristotle Pagaltzis // 

Re: Structured Publishing -- Joe Reger shows the way...

[Henry Story]

Is  DOAP over Atom [1] an example of the type of solution you are  
suggesting James?
That looks good. But what if I want to annotate an entry with some  
RDF? In a recent
blog [2] I describe a cool bar in Zürich. I mention that I would also  
like to add
to my feed information pertaining to the description. So I would like  
for example to
say that my entry is about a particular bar, give the address of the  
bar, its geo location
perhaps, that it has free wifi, and that it is very friendly. This  
would allow search engines
to index much more structured information about the bar than they  
otherwise could. This would
allow Google Maps for example to give a location to my feedback on  
their maps. In the DOAP over
Atom type solution where the RDF is placed inside the content, there  
is then
no more space to put the entry content itself. So I can either put  
the text entry into the content

or the metadata. Where should the metadata go?

Henry Story

[1] http://www.codezoo.com/about/doap_over_atom.csp
[2] http://blogs.sun.com/roller/page/bblfish/20050910

On 10 Sep 2005, at 01:51, James M Snell wrote:

Bob Wyman wrote:


I’ve written a blog post pointing to a wonderful demo of tools for  
doing structured publishing in blogs that Joe Reger has put  
together. Given that Atom has built-in support for handling much  
more than just the text/HTML that RSS is limited to, I think this  
should be interesting to the Atom community.


http://bobwyman.pubsub.com/main/2005/09/joe_reger_shows.html

What can we do with Atom to make the vision of Structured/Semantic  
publishing more real?


bob wyman

There really isn't anything we HAVE to do with Atom to make it  
suitable for Structured publishing. The format's content model is  
already more than adequate for this kind of thing. For instance,  
Joe Reger's software could easily stuff the XML data instances that  
conform to a logs XML Schema into the atom:content element while  
including the text description of the log into the atom:summary.  
The only thing that really needs to happen here is for someone to  
begin writing the code that makes this happen.


- James