Subject: "Role of RSS in Science Publishing"

From: Danny Ayers <[email-masked]>
Date: Wed, 15 Dec 2004 21:22:30 +0100

fyi, A paper published today in D-Lib Magazine. Atom is mentioned,
also the article describes requirements that led them to RSS 1.0 that
probably should be taken into account with Atom. (I think some/all of
the authors are on this list - hi guys!)

        The Role of RSS in Science Publishing:
        Syndication and Annotation on the Web

        by Tony Hammond, Timo Hannay and Ben Lund,
           Nature Publishing Group

http://dx.doi.org/10.1045/december2004-hammond

-- 

http://dannyayers.com

---

From: Robert Sayre <[email-masked]>
Date: Wed, 15 Dec 2004 15:49:54 -0500

> the authors are on this list - hi guys!)

I wasn't aware that RSS2 and Atom aren't extensible!

+-----------( Figure 2 )-------------------------+
|                                                |
|              (Simple: Plain XML)               |
|                                                |
|            +---(0.91)--(0.92)--(2.0)--(Atom)   |
|            |                                   |
|            |                                   |
|  --(0.9)---+---(1.0)                           |
|                                                |
|              (Extensible: RDF/XML)             |
|                                                |
+------------------------------------------------+

Sigh...

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Thu, 16 Dec 2004 00:06:20 +0100

> I wasn't aware that RSS2 and Atom aren't extensible!

I wouldn't take it for granted. Myself, I've flip-flopped on these
questions a few times. I'm pretty sure "using XML syntax" isn't a
guarantee in itself. Depends (as usual) somewhat on definitions. For
'extensible' FOLDOC has:

"Said of a system (e.g., program, file format, programming language,
protocol, etc.) designed to easily allow the addition of new features
at a later date, e.g. through the use of hooks, an API or plug-ins."

Does RSS 2.0 allow addition of new features? Well yes, if you wheel in
the XML namespaces layer and simultaneous knock out the "Simple" of
syntax that caused the old fork. Was it designed for this? I reckon
that's pushing it a little. In practice it easily allows the addition
of new features in the sense that a human language easily allows new
words - you can have them, as long as you can get everyone to agree
their meaning. Pluggable, but every new plug needs a corresponding new
socket.

Does RSS 1.0 allow this? Yes, without a doubt, there is a complete
supporting framework/language in which it is straightforward to define
extensions on the same level as RSS (RDF/RDFS) or by building layers
on top (OWL, rules etc). The language is pluggable, there are hooks.
In human language terms, you can define new words based largely on
existing definitions, though they will usually also have additional
domain-specific meaning.

Does Atom allow this? That remains to be seen. Personally I'm hopeful
that we've got past the assumption that namespaces alone will save us,
and that we (will) have usable hooks which will make the format &
protocol genuinely extensible, rather than just inheriting an 'X' in
the title.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Dec 2004 10:32:13 +1100

On 16/12/04 10:06 AM, "Danny Ayers" <[email-masked]> wrote:

> In practice it easily allows the addition

The limit isn't universally true - there are a few languages that support
algorithmic creation of new words.  German, for one IIRC. Turkish too.

e.

---

From: Robert Sayre <[email-masked]>
Date: Wed, 15 Dec 2004 18:48:57 -0500

> at a later date, e.g. through the use of hooks, an API or plug-ins."

So you can't do that with RSS2 or Atom?

> on top (OWL, rules etc). 

Yes, but you can't use your standard RDF serializer to write the RSS1.

> The language is pluggable, there are hooks.

It is possible to understand RDF yet not want to use it.

> protocol genuinely extensible, rather than just inheriting an 'X' in

OK, fair enough. How about

   <entry
    xmlns="http://purl.org/atom/ns#draft-ietf-atompub-format-03"
    xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
     <title>Atom-Powered Robots Run Amok</title>
     <link href="http://example.org/2003/12/13/atom03"/>
     <id>vemmi://example.org/2003/32397</id>
     <updated>2003-12-13T18:30:02Z</updated>
     <rdf:RDF>...</rdf:RDF>
   </entry>

This is just like RSS1, except there's a URI identifying the entry, and 
the syntax defaults to XML literals. Also, you can use your standard RDF 
serializer to write your statements. Of course, you'll have to use an 
actual RDF parser to get them back out.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Thu, 16 Dec 2004 00:53:54 +0100

> algorithmic creation of new words.  German, for one IIRC. Turkish too.
 
Sure, my apologies.  

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 16 Dec 2004 00:30:07 +0000

Danny Ayers wrote:
> that's pushing it a little. 

It certainly does depend on your definition of extensible. Saying RSS2.0 
is extensible because I can drop in namespaced blocks is like saying my 
copy of the K&R is extensible because I can write notes in the margins.

cheers
Bill

---

From: Danny Ayers <[email-masked]>
Date: Thu, 16 Dec 2004 01:37:52 +0100

> So you can't do that with RSS2 or Atom?

Not really and not yet. See my previous post.

XML Namespaces can enable pluggability, but don't automatically
provide it. The core language (or a common underlying language) has to
provide some form of hooks into its constructs. RSS 2.0 is generally
lacking, Atom is getting there (IMHO).

> Yes, but you can't use your standard RDF serializer to write the RSS1.

True, but that doesn't mean it can't be done. And most of the time in
this context it really isn't an issue. My own RSS 1.0 feed is produced
using WordPress with the FOAF Output plugin, and last time I looked
used terms from 9 different namespaces. I'm fairly certain there's no
generalised RDF modelling going on, but the output is (usually)
spec-valid RSS 1.0 & also spec-valid RDF/XML. If I wanted to apply RDF
processing, or use RDF queries, I'd read the stuff into a store, along
with any other data I wanted to query in the same model (Before long I
probably will move to a primarily RDF backend, but probably still make
use of an RDBMS for the underlying store and templating for
presentation).

Whatever, currently the serialized data is still expressed in the rich
language, even though as far as my blog templates are concerned it's
dog-HTML.

> actual RDF parser to get them back out.

The URI on the entry is a very good hook into the core constructs, for
sure. Something like this could quite easily provide the same kind of
extensibility RSS 1.0 has - exactly the same kind really, assuming the
obvious triple interpretations of atom:title etc.

I'm not really trying to suggest that it wouldn't be fairly
straightforward to give Atom strong extensibility (or that RDF is
needed somewhere, though it does seem the easy way). Just that I think
the simple/extensible split in the Nature folk's diagram is (or maybe
was, until relatively recently) a fairly reasonable observation.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Eric Scheid <[email-masked]>
Date: Thu, 16 Dec 2004 12:28:22 +1100

>> algorithmic creation of new words.  German, for one IIRC. Turkish too.

no worries - my point was that while all languages generally share the same
basic characteristic (words conveying meaning), some languages are
architecturally better because they have extensibility built in.

rather like RDF/XML vs vanilla XML

e.

---

From: Ben Lund <[email-masked]>
Date: Thu, 16 Dec 2004 11:29:32 +0000

Robert Sayre wrote:
> This is just like RSS1, except there's a URI identifying the entry 

I'm not sure I understand your point here. RSS 1.0 certainly also has a 
URI identifying the entry (or 'item') -- the rdf:about attribute.  So 
this could be written as:

<item xmlns="http://purl.org/rss/1.0/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:dcterms="http://purl.org/dc/terms/"
   rdf:about="vemmi://example.org/2003/32397"
   <title>Atom-Powered Robots Run Amok</title>
   <link>http://example.org/2003/12/13/atom03"</link>
   <dcterms:modified>2003-12-13T18:30:02Z</dcterms:modified>

   <!-- extra RDF here -->

</item>

The RSS 1.0 spec doesn't mandate that an item's rdf:about be identical 
to it's <link>, just that it should be if possible.

Ta,
Ben

********************************************************************************
DISCLAIMER: This e-mail is confidential and should not be used by anyone who is not the original intended recipient. If you have received this e-mail in error please inform the sender and delete it from your mailbox or any other storage mechanism. Neither Macmillan Publishers Limited nor any of its agents accept liability for any statements made which are clearly the sender's own and not expressly made on behalf of Macmillan Publishers Limited or one of its agents. Please note that neither Macmillan Publishers Limited nor any of its agents accept any responsibility for viruses that may be contained in this e-mail or its attachments and it is your responsibility to scan the e-mail and attachments (if any). No contracts may be concluded on behalf of Macmillan Publishers Limited or its agents by means of e-mail communication. Macmillan Publishers Limited Registered in England and Wales with registered number 785998 Registered Office Brunel Road, Houndmills, Basingstoke RG21 6XS
********************************************************************************

---

From: Ben Lund <[email-masked]>
Date: Thu, 16 Dec 2004 11:40:46 +0000

Hi Danny,

Danny Ayers wrote:
> On Wed, 15 Dec 2004 18:48:57 -0500, Robert Sayre <[email-masked]>
>>>supporting framework/language in which it is straightforward to
> 
> define
> 
> True, but that doesn't mean it can't be done. 

And in fact it has been done ;-)

In Urchin we overrode RDF::Core::Model::Serializer to create an general 
RDF serializer that conforms to the RSS 1.0 restrictions (1).  As long 
as, of course, there's some data using the RSS 1.0 vocabulary in the 
model being serialized...

Ta,
Ben

1. 
http://cvs.sourceforge.net/viewcvs.py/urchin/urchin/Urchin/OutputFeed/RDF/Core/Model/Serializer.pm?rev=1.1&view=markup

---

From: James Robertson <[email-masked]>
Date: Thu, 16 Dec 2004 07:23:04 -0500

>copy of the K&R is extensible because I can write notes in the margins.

In practice, this objection is meaningless.  There are a number of 
namespaced modules that are used in RSS 2.0, and most aggregators 
understand them.  And the ones that don't bypass them without a problem.

This objection comes up all the time - and while there's a grain of truth 
to it, it's mostly nonsense

>Bill

<Talk Small and Carry a Big Class Library>
James Robertson, Product Manager, Cincom Smalltalk
http://www.cincomsmalltalk.com/blog/blogView
Cincom Smalltalk User Conference!
http://www.cincomsmalltalk.com/blog/blogView?entry=3275631428

---

From: Ben Lund <[email-masked]>
Date: Thu, 16 Dec 2004 12:38:41 +0000

James Robertson wrote:
>> It certainly does depend on your definition of extensible. Saying 
>> RSS2.0 is extensible because I can drop in namespaced blocks is like 
>> saying my copy of the K&R is extensible because I can write notes in 
>> the margins.
> 
> 
> This objection comes up all the time - and while there's a grain of 
> truth to it, it's mostly nonsense
> 

That depends entirely on the application you have in mind.  For end- 
aggregators, it's mostly fine that they can ignore things they don't 
understand.  But what about aggregating intermediaries?  Unless there's 
a defined extensibility model, there's a large chance that the extra 
data in the exensions that the aggregator doesn't understand will be 
lost.  RDF in RSS 1.0 make this a very simple problem to solve, whereas 
arbitrary XML namespaces makes it fiendishly difficult.

Ta,
Ben

---

From: Graham <[email-masked]>
Date: Thu, 16 Dec 2004 13:11:58 +0000

On 16 Dec 2004, at 12:38 pm, Ben Lund wrote:
> understand.  But what about aggregating intermediaries?  Unless 
> there's a defined extensibility model, there's a large chance that the 
> extra data in the exensions that the aggregator doesn't understand 
> will be lost.  RDF in RSS 1.0 make this a very simple problem to 
> solve, whereas arbitrary XML namespaces makes it fiendishly difficult.

What's difficult about just copying everything through? Why can't you 
do that? I can't think of any problems that wouldn't equally apply to 
RDF.

Graham

---

From: Robert Sayre <[email-masked]>
Date: Thu, 16 Dec 2004 08:30:50 -0500

> this could be written as:

Would you use the rdf:about attribute as a GUID? I sure wouldn't. It 
doesn't identify the statements themselves.

> to it's <link>, just that it should be if possible.

Someone should compile a list of the recommendations in that spec that 
are OK to ignore.

Robert Sayre

---

From: Robert Sayre <[email-masked]>
Date: Thu, 16 Dec 2004 08:40:20 -0500

> arbitrary XML namespaces makes it fiendishly difficult.

Could you show us an example? I'm having a hard time understanding why 
the intermediary could pass on blobs of (X)HTML but not blobs of XML.

I also don't understand why including rdf:RDF in atom:entry is 
insufficient. You'd have to consume it with an RDF parser and it would 
come in a container that isn't RDF itself, but I don't see a problem. It 
would eliminate the people pretending to use RDF that actually 
aren't--they remind me of American teenagers who get tatoos featuring 
chinese glyphs.

Robert Sayre

---

From: Danny Ayers <[email-masked]>
Date: Thu, 16 Dec 2004 14:53:32 +0100

> do that? I can't think of any problems that wouldn't equally apply to

What if they receive multiple, non-identical versions of the same
entry from different sources?
Admittedly there isn't a conflict resolution defined for core RSS 1.0
components, e.g. where only a single value is mandated, but for
extensions (which we are talking about here) the RDF model is clear
(there is no conflict).

With RSS 2.0 in such a circumstance all you would have is two or more
XML fragments, without any specified means of gluing them together.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 16 Dec 2004 14:05:08 +0000

> understand them.  And the ones that don't bypass them without a problem.

If you are right, I take this as meaning RSS2.0 Atom doesn't require 
extensibility. They only require modularity, which XML+Namespaces provides.

cheers
Bill

---

From: James Robertson <[email-masked]>
Date: Thu, 16 Dec 2004 10:04:53 -0500

>extensibility. They only require modularity, which XML+Namespaces provides.

For the most common use case - news updates - that's the case.  I can't 
really speak to other potential uses.  However, I tend to take a dim view 
of functionality that is intended for "future needs" - we tend to be very 
bad at predicting real future needs

---

From: Graham <[email-masked]>
Date: Thu, 16 Dec 2004 16:07:11 +0000

> extensions (which we are talking about here) the RDF model is clear

Well you have 2 (or 3) choices:
1. Use the newer entry
2. a) Mix all the elements in one <entry> container
or b) as a), but remove duplicately named elements.

Option 1 requires app-specific knowledge, which RDF can't help you 
with. Neither 2a or 2b will necessarily produce valid results, but 
again, I'm not aware of a feature in RDF that will help.

(also please don't use the word "receive", we request things around 
here)

Graham

---

From: "Bill Kearney" <[email-masked]>
Date: Thu, 16 Dec 2004 11:10:16 -0500

> doesn't identify the statements themselves.

For an <item> that's exactly what it's intended to provide.

> Someone should compile a list of the recommendations in that spec that

That's not what's involved.  One has to appreciate the reasons RSS has been
used, over time, to grasp why the link and item about URL have been
interchangeable.  Since tools existed that expected a link to be present it
wasn't a good idea to take it out.  Many feeds, at the time, used the item
to say something about what the link pointed toward.  In those feeds there
was no expectation that the item would have it's own web page.  This was a
debate that raged for quite a while.  The emergence of easy weblogging tools
changed that.  But then half-assed RSS spec hijacking screwed up unique
identifiers.

-Bill Kearney
Syndic8.com

---

From: Ben Lund <[email-masked]>
Date: Thu, 16 Dec 2004 16:25:35 +0000

Robert Sayre wrote:
> Ben Lund wrote:
> 
>>
>> I'm not sure I understand your point here. RSS 1.0 certainly also has 
>> a URI identifying the entry (or 'item') -- the rdf:about attribute.  
>> So this could be written as:
> 
> 

Ah, I see. No, the item's URI doesn't identify a set of statements, but 
it is the common subject for that set.  I'd be interested in working out 
whether there's a practical difference between those two concepts.

> Someone should compile a list of the recommendations in that spec that 

;-)
The spec itself is pretty clear on this one though:

"{item_uri} should be identical to the value of the <link>  sub-element 
of the <item> element, if possible."

(http://web.resource.org/rss/1.0/spec#s5.5)

Ta,
Ben

---

---

From: Ben Lund <[email-masked]>
Date: Thu, 16 Dec 2004 17:07:40 +0000

> the intermediary could pass on blobs of (X)HTML but not blobs of XML.

Sure (but bear in mind that I said it would be fiendishly difficult, not 
impossible):

I'm thinking of two use cases here:

1) Aggregating information where two different trusted sources both 
publish data about the same item.  For example, a feed from a science 
publisher that gave the bibliographic metadata, and a feed from a 
citation indexer gave 'cited by' information.  How does the intermediary 
concatenate the two blobs of XML?  Remember, I'm talking about 
situations where the intermediary doesn't understand the namespace being 
used, so from the point of view of the aggregator, the two blobs look 
like this:

<entry>
   <id>http://www.example.com/item1</id>
   <title>Blah blah</title>
   ...
   <xyz:tag1>gfdgfdgfd</xyz:tag1>
   <abc:tag2>
    <xyz:tag3>gfdgfd</xyz:tag3>
    <xyz:tag3>65454343</xyz:tag3>
   </abc:tag2>
</entry>

and

<entry>
   <id>http://www.example.com/item1</id>
   <title>Blah blah</title>
   ...
   <xyz:tag4>gfdgfd</xyz:tag4>
   <xyz:tag4>bvcbvvcbvc</xyz:tag4>
   <xyz:tag4>ytytryrt</xyz:tag4>
   <xyz:tag4>6768875</xyz:tag4>
</entry>

There's no easy way of working out how to combine this information. 
However, with RDF, you can just concatenate the triples.

2) Aggregating feeds from different sources, and then allowing new feeds 
to be generated based on queries to arbitrary fields.
This means that the aggregator has to capture any incoming data in some 
sort of schema.  In my experience its easier to do that if that incoming 
data already has a data model more contrained than the XML hierarchical 
model.

> come in a container that isn't RDF itself, but I don't see a problem. 

My view is that the RDF model buys you everything you need at the moment 
for an extensibility model -- that's why we use RSS 1.0 currently.  So, 
I don't particularly have a problem with the approach of putting rdf:RDF 
in an atom:entry. But that does beg the question of why Atom needs two 
separate data models.

Ta,
Ben

---

From: Danny Ayers <[email-masked]>
Date: Thu, 16 Dec 2004 18:35:16 +0100

> again, I'm not aware of a feature in RDF that will help.

What helps in RDF is that according to the model, there is no such
ambiguity at the common language level - there are no choices. This
provides independence, orthogonality between the message-passing and
the application-level interpretation.

For example, say the following came from sourceA:

<item>
   <xx:season>Spring</xx:season>
</item>

the following from sourceB:

<item>
   <xx:season>Summer</xx:season>
</item>

assuming both items have the same id (however expressed), everything
else removed for clarity

The RDF interpretation would be two statements, which could be wrapped
back up into pseudo-RSS as:

<item>
   <xx:season>Spring</xx:season>
   <xx:season>Summer</xx:season>
</item>

The RDF/XML interpretation mechanism provides clear communication of
data within a known data model. It's an unambiguous message in this
model. What the application does with it is another matter - it's a
different layer. But without such a mechanism, the choices are back
down at the level of XML syntax, there isn't even a domain-specific
grammar to draw on.

> (also please don't use the word "receive", we request things around

I'd suggest this all occurs above the wire protocol, but ok, I'll try not to ;-)

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Laurent Le Meur" <[email-masked]>
Date: Fri, 17 Dec 2004 18:05:19 +0100

>However, with RDF, you can just concatenate the triples.

You must bear in mind that the atom:id element "conveys a permanent, globally unique
identifier for the entry". It does identify the set of statements, and is not (like
the RSS item_uri) the common subject for that set. So if two aggregated entries have
the same atom:id, they must be coming from a unique provider and represent the same
information (or revision of the same information).

>in an atom:entry. But that does beg the question of why Atom needs two

Could it be because RDF is good for the representation of metadata (about some remote
content or resource), but Atom is also there to *embed* content?

Laurent Le Meur
AFP

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

This e-mail, and any file transmitted with it, is confidential and  intended solely for the use of the individual or entity to whom it is addressed. If you have received this email in error, please  contact the sender and delete the email from your system. If you are  not the named addressee you should not disseminate, distribute or copy  this email.

For more information on Agence France-Presse, please visit our web site at http://www.afp.com

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

---

From: Robert Sayre <[email-masked]>
Date: Fri, 17 Dec 2004 16:21:20 -0500

Ben Lund wrote:

> for an extensibility model -- that's why we use RSS 1.0 currently.  

Sure, but not many people use RSS1 correctly. I just saw this:
<dc:subject>java programming security staticanalysis</dc:subject>

More interesting in a plain old text search engine.

> So, 

RSS1 has two separate data models as well--the RSS1 spec amounts to an 
XML schema. Putting rdf:RDF in an Atom document is going to get you 
cleaner data.

"The use of the enclosing <rdf:RDF> tag implies a choice and a 
contract... The contract is that you're adhering to this choice into the 
future, and to the constraints this places on the syndication format, 
and the underlying model of the data."[0]

It would be wishful thinking to say a large percentage of RSS1 feeds are 
following that contract.

Robert Sayre

[0] http://www.imc.org/atom-syntax/mail-archive/msg00214.html

"given that the RSS 1.0 spec utilizes RDF, I believe that the tools and 
format itself should be RDF aware _from the start_.  A solid foundation 
is key to building anything that is going to last. This means that it is 
the *data model* that is important, not the physical syntax of "start 
with channel, then several items, etc".  In fact, I believe the spec 
itself should be an RDF Schema depicting the data model, with simple 
examples of how to express it in XML.  Anything less results in 
confusion and a mish-mash of incompatible tools, where some are simple 
XML processors and some are full RDF-aware processors.  I see this as 
the largest hurdle for RSS as RDF, given the comparative lack of RDF 
tools to XML tools.  If we are not willing to commit to this in the spec 
and tools, then we may as well go back to a plain XML format.  In other 
words, put up or shut up. "

--Dan Libby
http://groups.yahoo.com/group/syndication/message/586

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 17 Dec 2004 18:17:37 -0500

> However, with RDF, you can just concatenate the triples.
	Would that really be the right thing to do? In the example you gave,
the two different sets of triples were generated by different authors and
thus had differing contexts, trust metrics, authorship, etc. associated with
them. My gut feeling tells me that "source" information would need to be
preserved in most practical cases. While I see that in theory, simply
concatenating the triples makes sense -- I'm not sure if it would make sense
in the real world. Authorship/Attribution is important.

		bob wyman

---

From: Danny Ayers <[email-masked]>
Date: Sat, 18 Dec 2004 01:04:08 +0100

On Fri, 17 Dec 2004 18:17:37 -0500, Bob Wyman <[email-masked]> wrote:
>         Would that really be the right thing to do?

Heh, thought that point might bite back...depends...

 In the example you gave,
> in the real world. Authorship/Attribution is important.

True, but it's not a problem. Provenance can be done where needed
using reification (you add a pile more triples) or by stepping outside
the current RDF logic and using things like named graphs.

Cheers,
Danny.

-- 

http://dannyayers.com

---

From: "Bob Wyman" <[email-masked]>
Date: Fri, 17 Dec 2004 23:46:53 -0500

Danny Ayers wrote:
> Provenance can be done where needed using reification (you add a 
> pile more triples) or by stepping outside the current RDF logic and
> using things like named graphs.
	Please forgive me for not understanding RDF well enough to
understand your comment as well as I would like to. Could you help me out
here by providing an example of how two sets of triples could be
concatenated while still preserving provenance?

		bob wyman

---

From: Danny Ayers <[email-masked]>
Date: Sat, 18 Dec 2004 11:44:29 +0100

On Fri, 17 Dec 2004 23:46:53 -0500, Bob Wyman <[email-masked]> wrote:

Could you help me out
> concatenated while still preserving provenance?

Please allow me me lead up to an example slowly...
I've not really spent any time around provenance, but three approaches
spring to mind, Well, actually the first approach is ad hoc-ness on
the part of the RDF library developer - there are quite a few
different specific tricks, e.g. Redland I believe associates every
statement with a "context" so the context can provide any provenance
info. These sort of things are fine internal within a system but
aren't too helpful if you want to share that info and/or use it as
part of the RDF (RDFS/OWL) inferencing.

Long-term (i.e. it's unlikely to be in a W3C spec in the near future)
there's Named Graphs as a very promising extension of RDF, for which
the theory has been worked out and is nice & intuitive. Simple idea -
you can give any set of statements a URI. (This is kind of what a lot
of people seem to do anyway - e.g. I can consider my RSS feed as a
single, isolated graph with the URI of the feed. But the Named Graph
formalism makes it possible to mix 'em all up and still be able to
reason properly).

To quote from [1]:
"Named Graphs allow publishers to communicate assertional intent, and
to sign their graphs; information consumers can evaluate specific
graphs using task-specific trust policies, and act on information from
those Named Graphs that they accept."

A third approach to provenance is already supported by RDF,
reification. I still get very confused over this, Shelley Powers
called it "The Big Ugly". It's a bit like quotation but /different/ -
there is explanation in the Primer [2]. I've not used it myself, but a
presentation I saw last week convinced me the approach can work - Rich
Boakes on his RDFX [3] project,  uses reification expressly for the
purpose of provenance, it's clear in his slides [4].

Basic idea is that say for a triple:

mydata:item123   dc:subject   "fishing" .

you can reify it to add the triples: 

mydata:triple321   rdf:type        rdf:Statement .
mydata:triple321   rdf:subject     mydata:item123 .
mydata:triple321   rdf:predicate   dc:subject . 
mydata:triple321   rdf:object      "fishing" .

now you can say things about the triple, e.g.

mydata:triple321 dc:source http://example.org/feed

So whenever a statement is added to your knowledgebase, another 5+ are
thrown in too. I asked Rich the obvious question - yes, it is a big
overhead in terms of the amount of data that needs to be stored, but
(if I remember correctly) wasn't a great cost in terms of
computational complexity or difficult code. He just saw the extra bulk
as a necessary cost.

Cheers,
Danny.

[1] http://www.hpl.hp.com/techreports/2004/HPL-2004-57.html
[2] http://www.w3.org/TR/rdf-primer/#reification
[3] http://www.rdfx.org/
[4] http://www.rdfx.org/docs/presentation/SWAP_Boakes_AFrameworkForUnifiedInformationBrowsing.ppt

-- 

http://dannyayers.com

---

From: Bill de hÓra <[email-masked]>
Date: Sat, 18 Dec 2004 12:39:43 +0000

Danny Ayers wrote:

> Redland I believe associates every

4Suite also does something this. I'd speculate that most uses of RDF in 
production/commercial scenarios are using quads.

> the theory has been worked out and is nice & intuitive.

That's good to hear, because the provenance issues do tend to limit RDF 
usefulness.

> presentation I saw last week convinced me the approach can work 

Reification only works because it's a semantic free for all - there's no 
consensus as to what it means, so you can pretty much get it to mean 
anything you want to mean [it's like our link extension construct but 
worse]. The fact that we can say it's a bit like quotation while 
describing it being used for provenance is a something of a issue - 
never mind that reification does not appear do what it was designed to 
do, which is different again from quotation or provenance, or that none 
of those things are reification in the technical sense of the word. Ack. 
It's a lasting regret from my time on the RDF WG that we didn't get rid 
of it.

cheers
Bill

---

From: David Powell <[email-masked]>
Date: Sat, 18 Dec 2004 15:58:31 +0000

On Saturday, December 18, 2004, 10:44:29 AM, Danny Ayers wrote:

> spring to mind

Perhaps part of the problem is related to modelling dynamic data using
a static model. Another approach would be to model those updates,
rather than attempt to resolve them into a static model at the RDF
level.

This would require a vocabulary that explicitly supports an
indirection between the item in the feed, and a particular state of
the item in the feed.

Eg, if RSS 1.0, looked something like this:

<rss:item rdf:about="http://example.com/myitem">
  <ex:itemState>
    <ex:ItemState>
      <rss:title>whatever</rss:title>
      <!-- more properties -->
      <ex:modified>2004-12-18</ex:modified>
      <ex:source rdf:resource="http://example.com/source" />
    </ex:ItemState>
  <ex:itemState>
</rss:item>

Then it would be possible to attach provenance information and
temporal information to a particular version of an item in the feed.

The choice of which state of an item to display could then be done at
the application level, and it would be fairly easy to support
extensions like delayed publishing, expiry, and deletion of items.

-- 
Dave

---

From: Henry Story <[email-masked]>
Date: Sat, 18 Dec 2004 18:21:30 +0100

I would like to suggest that Atom already is an RDF format. I have 
shown that it is [1], we just need to formalize this as I suggested in 
[2].

Let us do the journey from RDF triples to Atom format once again. Let 
us take the example in the current Atom spec and draw it as a triple 
graph.

_f1 ---a------> <Feed>
   |--- head---> _e1 ---a-----> <Entry>
   |              |---title---> "Example Feed"
   |              |---link----> <http://example.org/>
   |              |--updated--> "2003-12-13T18:30:02Z"^^xsd:dateTime
   |              |---author--> _a1 ---a-----> <atom:Person>
   |                             |----name---> "John Doe"^^xsd:string
   |
   |---entry---> _e2 ---a-----> <Entry>
                  |---title---> "Atom Powered Robots Run Amok"
                  |----id-----> <vemmi://example.org/2003/32397>
                  |--updated--> "2003-12-13T18:30:02Z"^^xsd:dateTime

The above shows an anonymous node _f1, which is of class atom:Feed 
related to two other anonymous nodes _e1 and _e2, of type Entry. (That 
these are of type entry is still controversial, but it makes the point 
I am making easier to understand). _e1 is related to a Person anonymous 
noted by the atom:author property. All that is known of the person is 
their name "John Doe" which is an xsd:string.

If we now follow the steps of the RDF/XML syntax specification [3] for 
converting a graph into XML we get the following transformations.

1. Simple RDF/XML
------------------

Here is perhaps the easiest to understand serialisation of the above 
graph.

<rdf:Description>
     <rdf:type>
	  <rdf:Description rdf:about="&atom;Feed">
       </rdf:Description>
     </rdf:type>
     <head>
	  <rdf:Description>
           <rdf:type>
	        <rdf:Description rdf:about="&atom;Entry">
             </rdf:Description>
           </rdf:type>
           <title>Example Feed</title>
           <link>
	        <rdf:Description rdf:about="http://example.org/">
             </rdf:Description>
           </link>
           <updated>2003-12-13T18:30:02Z</updated>
           <author>
	        <rdf:Description>
                <rdf:type>
	             <rdf:Description rdf:about="&atom;Person">
                  </rdf:Description>
                </rdf:type>
                <name>John Doe</name>
             </rdf:Description>
           </author>
       </rdf:Description>
     </head>
     <entry>
	  <rdf:Description>
           <rdf:type>
	        <rdf:Description rdf:about="&atom;Entry">
             </rdf:Description>
           </rdf:type>
           <title>Atom Powered Robots Run Amok</title>
           <id>
	        <rdf:Description rdf:about="vemmi://example.org/2003/32397">
             </rdf:Description>
           </id>
           <updated>2003-12-13T18:30:02Z</updated>
       </rdf:Description>
     </entry>
</rdf:Description>

2. Simplifications
------------------

-simplify empty elements <prop><rdf:Description rdf:about="xxx"/></prop>
         to               <prop rdf:resource="xxx/>
-typed node element simplification for Feed type
-omitting blank nodes with the rdf:ParseType="Resource"

<Feed>
    <head rdf:ParseType="Resource">
           <rdf:type rdf:resource="&atom;Entry"/>
           <title>Example Feed</title>
           <link rdf:resource="http://example.org/"/>
           <updated>2003-12-13T18:30:02Z</updated>
           <author rdf:ParseType="Resource">
                <rdf:type rdf:resource="&atom;Person"/>
                <name>John Doe</name>
           </author>
     </head>
     <entry rdf:ParseType="Resource">
           <rdf:type rdf:resource="&atom;Entry"/>
           <title>Atom Powered Robots Run Amok</title>
           <id rdf:resource="vemmi://example.org/2003/32397"/>
           <updated>2003-12-13T18:30:02Z</updated>
     </entry>
</Feed>

3. OWL and xml schema simplifications
-------------------------------------

  - One can specify (apparently) in xml schema that a head, entry and 
author tags
    automatically have an rdf:ParseType="Resource". These can then be 
removed.
  - an owl file could specify that atom:href is a subproperty of 
rdf:resource, and so
    alloow us to replace rdf:resource with atom:href
  - finally we don't need to specify the rdf:types of the remaining 
elements as these
    are specified in the OWL file

<Feed>
    <head>
           <title>Example Feed</title>
           <link href="http://example.org/"/>
           <updated>2003-12-13T18:30:02Z</updated>
           <author rdf:ParseType="Resource">
                <rdf:type rdf:resource="&atom;Person"/>
                <name>John Doe</name>
           </author>
     </head>
     <entry>
           <title>Atom Powered Robots Run Amok</title>
           <id href="vemmi://example.org/2003/32397"/>
           <updated>2003-12-13T18:30:02Z</updated>
     </entry>
</Feed>

As a result we have something that is very very very close to our 
current Atom syntax.
Since we have a format that is rdf it is now very clear how it can be 
extended.

Question:
---------

Would this give you what you are looking for?

Henry Story

[1] http://www.imc.org/atom-syntax/mail-archive/msg11317.html
[2] http://www.imc.org/atom-syntax/mail-archive/msg11640.html
[3] http://www.w3.org/TR/rdf-syntax-grammar/