W3C home > Mailing lists > Public > semantic-web@w3.org > July 2008

Re: Atom Triples Internet Draft

From: Mark Birbeck <mark.birbeck@webbackplane.com>
Date: Fri, 4 Jul 2008 12:36:09 +0100
Message-ID: <ed77aa9f0807040436r5030ba02kf6fa51773579fcab@mail.gmail.com>
To: "Niklas Lindström" <lindstream@gmail.com>
Cc: "Dave Beckett" <dave@dajobe.org>, mnot@pobox.com, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "Story Henry" <henry.story@bblfish.net>, "semantic-web@w3.org" <semantic-web@w3.org>

Hi Niklas,

I won't comment on all of your post, just a couple of small things:

> I think that "Atom Triples" can be somewhat equivalent to Atom as RDFa
> is to XHTML.

RDFa was designed for use with *any* mark-up, since the parsing
algorithms are defined merely in terms of navigating a tree. So the
parsing would work on any XML-based language, such as SVG or Atom, and
of course with HTML.

> [snip]
> 8. It may be enough to use elements only when making literal
> statements, and to use atom:link for resource references.
> Since atom:link @rel values must be URI:s (or one of the predefined
> set of names), it seems viable to treat this similarly to RDFa - that
> is interpret @rel as the predicate URI (i.e. not a qname as in RDFa)...

Actually, @rel/@rev values are CURIEs, which are more flexible than QNames:

  * the part after the colon can be anything, not just an 'XML name';

  * a host language is free to define further 'fixed' values, alongside
    the built-in ones like 'license', 'next', etc.;

  * a host language is free to define its own method for defining prefixes.

This last issue is probably quite relevant here, since it means that a
language is not forced to rely solely on @xmlns to define how the
prefix is set.

> ...and @href as the object URI. Furthermore, one could stipulate that
> elements within atom:link elements can be interpreted as statements as
> well, with the value of @href as subject.

This would just 'fall out' if some RDFa mark-up was added to Atom, and
an RDFa parser used to process it.

> 9. To put this together, consider this rough sketch:
>    <feed xmlns="..."
>          xmlns:at="..."
>          xmlns:dc="..."
>          xmlns:foaf="...">
>        <at:entrymap rdf-namespace-prefixes="dc foaf">
>            <at:subject element="id"/>
>            <at:map property="foaf:name" element="title"/>
>        </at:entrymap>
>        <entry>
>            <id>http://purl.org/NET/dust/foaf#me</id>
>            <title>Niklas Lindström</title>
>            <foaf:givenname>Niklas</foaf:givenname>
>            <summary>About Niklas.</summary>
>            <content src="http://neverspace.net/me.html" type="text/html"/>
>            <link rel="http://www.w3.org/1999/02/22-rdf-syntax-ns#type"
>                  href="http://xmlns.com/foaf/0.1/Person"/>
>            <link rel="http://xmlns.com/foaf/0.1/homepage"
> href="http://neverspace.net/">
>                <dc:title xml:lang="en">Neverspace</dc:title>
>            </link>
>        </entry>
>    </feed>
> , yielding the following RDF (in Turle notation):
>    <http://purl.org/NET/dust/foaf#me> a foaf:Person;
>        foaf:name "Niklas Lindström";
>        foaf:givenname "Niklas";
>        foaf:homepage <http://neverspace.net/> .
>    <http://neverspace.net/> dc:title "Neverspace"@en .

I'd suggest a slightly different approach. First, I'd add the RDFa
@about to 'entry' to give you the subject of the statements:

  <entry about="http://purl.org/NET/dust/foaf#me">

Next, I'd add a single element that allows properties to be set.
Yahoo!'s DataRSS adds the 'meta' element which seems a reasonable
enough choice, and mirrors what we've done in XHTML 2.

Whatever the element is, it would allow the RDFa attributes @property,
@content and @datatype.

There are two reasons that I think this is better than simply placing
elements in 'entry'.

The first is that space is then left for Atom to add whatever it wants
to in the future, and it is clear where the metadata for Atom itself,
versus the metadata being carried, are distinct.

Second, QNames don't allow for all possible resources--a problem that
RDF/XML has, too.

So, the plain literals in your example would become:

    <title>Niklas Lindström</title>
    <meta property="foaf:givenname">Niklas</meta>
    <summary>About Niklas.</summary>
    <content src="http://neverspace.net/me.html" type="text/html"/>

Now, @rel is used slightly differently in RDFa, but before we get to
that, RDFa supports @typeof which is a shorthand for rdf:type, so we
can remove the first 'link' in your example. @typeof needs to go with
the subject though, so the 'entry' would now look like this:

  <entry about="http://purl.org/NET/dust/foaf#me" typeof="foaf:Person">

Nested statements in RDFa are 'about' the object of the parent (if
present), so the next part of your example is easily converted to the
following (ignore @rel again, for the moment):

    <link rel="http://xmlns.com/foaf/0.1/homepage"
      <meta property="dc:title" xml:lang="en">Neverspace</meta>

In RDFa, @rel would hold a CURIE, which is usually a prefix/suffix combination:

    <link rel="foaf:homepage" href="http://neverspace.net/">
      <meta property="dc:title" xml:lang="en">Neverspace</meta>

But it can also come from a set of predefined values, such as:

    <link rel="homepage" href="http://neverspace.net/">
      <meta property="dc:title" xml:lang="en">Neverspace</meta>

These values can be defined by a host language, possibly even dynamically.

The finished example, of using RDFa to carry RDF in Atom, might look like this:

  <entry about="http://purl.org/NET/dust/foaf#me" typeof="foaf:Person">
    <title>Niklas Lindström</title>
    <meta property="foaf:givenname">Niklas</meta>
    <summary>About Niklas.</summary>
    <content src="http://neverspace.net/me.html" type="text/html"/>
    <link rel="foaf:homepage" href="http://neverspace.net/">
      <meta property="dc:title" xml:lang="en">Neverspace</meta>



Mark Birbeck, webBackplane



webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)
Received on Friday, 4 July 2008 11:36:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 07:42:05 UTC