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

Re: Atom Triples Internet Draft

From: Story Henry <henry.story@bblfish.net>
Date: Fri, 1 Aug 2008 10:52:33 +0200
Cc: Niklas Lindström <lindstream@gmail.com>, Beckett Dave <dave@dajobe.org>, Mark Nottingham <mnot@pobox.com>, "Booth, David (HP Software - Boston)" <dbooth@hp.com>, "semantic-web@w3.org Web" <semantic-web@w3.org>, atom-owl@googlegroups.com
Message-Id: <040EF254-0173-475C-9525-7658DC2ECD96@bblfish.net>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
On 4 Jul 2008, at 13:36, Mark Birbeck wrote:
> 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.

I like the RDFa idea a lot. Btw, there would be a question as to the  
namespace of the rdfa attributes if it
were to work with atom.

> [snip]
> 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">
>    <id>http://purl.org/NET/dust/foaf#me</id>
>

Though that makes sense in a way, my feeling is that an atom:Entry is  
an information object,
and so is owl:disjointWith a foaf:Person . I would argue this by  
looking at the main use case for atom: the Atom Protocol. Atom entries  
get published, are GETable, etc. Human beings are not. There is  
furthermore the problem of it being possible to have multiple entries  
with the same id, which would suggest that at the very most an entry  
would have to be a time slice of a person, not the full person.  
Certainly you would not want the about url to be the same as the atom  
id, that would make updates impossible.

If people want to use AtomPub to publish information about people,  
they should really place a foaf file in the content. If you want to  
specify information about the state of people at different times of  
their life one should develop at time slice ontology [1] for people  
( perhaps as part of a Resume ontology ), and add information about  
people to their slices. Something like

:hs :during [ :from "1996-10-01"^^xsd:Date; :to "2001-08-01"^^xsd:date;
               :workedFor [ foaf:homePage <http://altavista.com> ] .


Even though the semantic makes it easy to extend things, logic will  
set limits to what can be said. A Person is not a document. So perhaps  
it would be worth considering some slightly more realistic examples...

You could then use atom to publish that, and people subscribing to  
your feed, would have a way to know about all the resources you  
updates without being forced to crawl all your site. So atom is still  
very useful. It just does not need to be forced to do every thing.



Henry


[1] CYC has some such construct here
     http://www.cyc.com/cycdoc/vocab/top-vocab.html#timeSlices


> 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"
> href="http://neverspace.net/">
>      <meta property="dc:title" xml:lang="en">Neverspace</meta>
>    </link>
>
> 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>
>    </link>
>
> 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>
>    </link>
>
> 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">
>    <id>http://purl.org/NET/dust/foaf#me</id>
>    <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>
>    </link>
>  </entry>
>
> Regards,
>
> Mark
>
> -- 
> Mark Birbeck, webBackplane
>
> mark.birbeck@webBackplane.com
>
> http://webBackplane.com/mark-birbeck
>
> 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, 1 August 2008 08:55:41 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 21:45:24 GMT