All the while Factor is making it painful to use ‘mainstream’ languages as I get used to some of these basic abstractions!

I suspect that by getting rid of the 10%, you also lose the 90%.

One question - a Semantic Web without URIs in the RDF, where’s the Web bit? That an agent can follow it’s nose (do a GET) to find more information is a feature, no?

Manuel, the triplestore/search engine is a bit apples/oranges - most search engines have some kind of database under the hood, the database itself will require fairly exact input.

Going the other way, a triplestore with SPARQL can make a very simple backend to a search engine, e.g. to find anything with the word “primer” in it:

SELECT DISTINCT ?o
WHERE {
?s ?p ?o .
FILTER regex( ?o, ‘primer’, ‘i’ )
}
LIMIT 10

try pasting it in here:
http://hyperdata.org/sparql/demo/sparql-editor.html

A triple store requires very exact inputs to deliver any data at all. In contrast, a search engine’s motto is to “deliver results no matter what”.

Basically, indexing and (page-)ranking all “title literals” (wikinames, blog titles, …) should do the job, you probably wouldn’t need a fulltext search engine.

And let’s not forget the R in REST - a triple store has to return triples, whereas a search engine can return any representation, even a movie clip, which is a much better model for user facing systems.

Pretty much any data format can be treated as a (domain-specific) RDF serialization by specifying a mapping between the format and the RDF model (”micromodels” or “Custom RDF Dialects“). A bunch of folks have been working on such a mapping for Atom for a while now, albeit very intermittently.

The mapping is harder than one might first think because of Atom’s relatively complex structure (compared to say RSS). While stuff like the expression of content can be done in RDF in a more or less direct mapping as you demonstrate, the really tricky bit is around IDs (Henry Story’s done a lot of work on this, though he now reckons he might have been overengineering a little).

But all being well we’ll have some agreement on a preferred mapping pretty soon, and there’s the possibility that Atom might then become GRDDL-enabled (technicially this part’s straightforward, all it needs is a tweak to the namespace doc plus the mapping in XSLT). As and when that happens, to any GRDDL-aware agent, every existing Atom doc will be an RDF doc, without any effort from the doc publisher.

So, “…could OWL realistically be used to allow an RSS1.0 app to interpret atom data?”.

Hmm, as Bob suggests it may be possible to express equivalences that an OWL reasoner could make sense of, but I think there’s an easier route through a word he uses: queries.

If you wanted to create RSS 1.0 from Atom expressed in RDF, you could do it using SPARQL with something like:

CONSTRUCT {
?item1 rss1:description ?desc
} WHERE {
?entry1 atom:content ?content1 .
?content1 atom:type “xhtml” .
?content1 atom:value ?desc .
}

The tool Dave Beckett’s set up is triplr, which can transform between lots of different serializations - but I’ve just noticed it chokes on Atom’s namespace, presumably because it doesn’t have a # or / at the end. I’d better ping him…

http://triplr.org/rdf/planet.intertwingly.net/memes.atom
etc.

#item1 rss1:description "foobah"

whereas the atom RDF for content would be something like :

#entry1 atom:content #content1
#content1 atom:type "xhtml"
#content1 atom:value "foobah"

Does that make sense?

Thanks for the reply.
I suspect the devil is in the detail. For example how would you map RSS1.0’s item ‘description’ and Atom’s entry ‘content’?. The former is a literal property but the latter is structured object.

<owl:Class rdf:about=”http://purl.org/rss/1.0/item”>
<equivalentClass rdf:resource=”http://purl.org/atom/ns#draft-ietf-atompub-format-08/entry”/>
</owl:Class>

I learned from a recent Talis podcast that Dave Beckett has something that I believe will let you treat Atom documents as RDF, which would be a significant step toward implementing this.

Bob DuCharme