Re: Atom Triples Internet Draft

Just a quick note in this thread. POWDER (Protocol for Web Description 
Resources) is close to Last Call on some of its documents, notably [1, 
2]. In section 4.1.3 of [1] we give an example of linking an Atom feed 
and an individual entry within it to a POWDER document, the processing 
of which can reveal triples about multiple resources, such as all the 
elements in the feed.

The key thing for this discussion is that in a Rec Track document, we're 
already showing how one can add RDF directly to an Atom feed. I just 
hope we got it right so far!

Phil.

-- 
Phil Archer
Chief Technical Officer,
Family Online Safety Institute
w. http://www.fosi.org/people/philarcher/

[1] http://www.w3.org/TR/powder-dr/
[2] http://www.w3.org/TR/powder-grouping/

Story Henry wrote:
> Thanks Dave for this proposal to link atom and rdf.
> 
> A few remarks:
> 
> 1. one can already embed rdf in atom
> ------------------------------------
> 
> Just as a matter of interest for those who do not know the atom format, 
> one can already embed rdf in atom quite simply.
> 
> <entry>
>       <title>syndeocms Project</title>
>       <link href="http://doapspace.org/doap/sf/syndeocms"/>
>       <id>http://doapspace.org/doap/sf/syndeocms</id>
>       <updated>2007-12-13T18:30:02Z</updated>
>       <summary>Some text..</summary>
>       <content type="text/rdf+n3">
>            @prefix doap: &lt;http://usefulinc.com/ns/doap#&gt; .
>            &lt;http://projects.com/1&gt; a doap:Project;
>                                          doap:name "Project 1" .
>       </content>
> </entry>
> 
> It is interesting to think about what the Atom Triples proposal adds to 
> this. More below.
> 
> 2. Mappings from Atom to RDF already exist
> ------------------------------------------
> 
> As another point of reference one has to point out that links between 
> rdf and atom are being worked on.
> Projects such at the atom-owl group have started looking at designing an 
> ontology and a mapping for this.
>     http://groups.google.com/group/atom-owl
> The latest spec is available here:
>         http://bblfish.net/work/atom-owl/2006-06-06/AtomOwl.html
> with XSLT and XQuery transforms. David Powell has also worked on what 
> turns out to be a nearly isomorphic ontology atom-rdf
> 
> Clearly that atom in the content has to be interpreted as a literal, 
> otherwise a feed with a number of entries saying contradictory things 
> could produce on GRDDL extraction a nonsensical graph. Ie, the content 
> is close to an N3 graph. We could nearly translate the example above 
> into the following N3
> 
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#>
> 
> [] a :Entry
>    :title "syndeocms Project";
>    :alternate <http://doapspace.org/doap/sf/syndeocms>;
>    :id "http://doapspace.org/doap/sf/syndeocms"^^xsd:anyURI;
>    :updated "2007-12-13T18:30:02Z"^^xsd:dateTime;
>    :summary "Some text";
>    :content {
>        @prefix doap: <http://usefulinc.com/ns/doap#> .
> 
>        <http://projects.com/1> a doap:Project;
>                                doap:name "Project 1" .
>    }
> 
> There is no general rule that one has to merge any two graphs one finds 
> on the internet. How, and when to merge two graphs is a matter of trust 
> and choice of lifting rules. RDF semantics does state rules about 
> merging two graphs one believes to be true.
> 
> The way atom is used though it is quite possible that two entries in the 
> same feed with the same id have contradictory content, the second entry 
> being an update of the first entry. Perhaps a mistake was made on first 
> publication. It follows therefore that the content above need not be 
> merged with the surrounding context, or with other content of different 
> entries in the same feed, let alone other feeds. As a result it is true, 
> it would not be the place to add new metadata about the feed or entry 
> objects themselves.
> 
> This points to the need of something like what is being proposed by the 
> AtomTriples specification.
> 
> 
> 3. embedding rdf in atom
> ------------------------
> 
> It is clearly stated in the introduction that the aim of this format is 
> to embed
> rdf in atom
> 
> [[
>    This specification describes AtomTriples, a set of Atom [RFC4287]
>    extension elements for embedding RDF
>    [W3C.WD-rdf-syntax-grammar-20031010] statements in Atom documents
>    (both element and feed), as well as declaring how they can be derived
>    from existing content.
> ]]
> 
> The at:md element does in fact allow the embedding of any rdf in the 
> atom feed or entry elements. The following statement is very odd though:
> 
> [[
>    Likewise, the mechanics of combining metadata from multiple instances
>    of the same entry, or from multiple feed documents, is out of the
>    scope of this specification.
> ]]
> 
> This cannot be right. You cannot use rdf in a format and yet say nothing 
> about how to use that RDF. RDF semantics makes it very clear how to 
> merge relations from different graphs. If you are embedding RDF in atom, 
> there has to be a way to make sense of what that embedding means, or 
> else how can one know that it is rdf that you have embedded in atom, and 
> not something completely different that just happens to look very much 
> like a well known serialisation of rdf?
> 
> That is, one has to have a story of what merged graphs looks like if one 
> believes all the information to be correct. Someone who publishes a feed 
> clearly makes a statement about the content of the feed, and the 
> statement should be taken on face value to say something true.
> 
> If one really does not want such a merge, then would the right place to 
> put this metadata not be the <content> element , where clearly we have a 
> literal, and there is no obligation to merge the log:semantics of 
> literals ?
> 
> Or are you saying that really the rdf in the at:md elements are 
> literals? So how then do they differ from the content then?
> 
> 
> 4. problems with at:md element
> ------------------------------
> 
> The at:md element allows one to place rdf anywhere in a feed or entry 
> element, and allows one to speak of anything.
> 
> [[
> The subject of these statements is, by default, the value of the
>    atom:id element in the same context (atom:element or atom:feed).
>    However, this behaviour MAY be overridden by specifying the subject
>    attribute.
> ]]
> 
> Since the rdf one can place inside the at:md element can be about 
> anything one wonders what the point of the default behavior in the spec 
> is about. It turns out that by default the subject of the at:md element 
> should be the resource identified by the atom:id of the feed or some 
> resource related by a link relation.
> Furthermore the way to find the URI of the link relation is extremely 
> contorted:
> 
> [[
>    It MUST contain a URI which MUST be interpreted as a link relation;
>    the first such occurrence of an atom:link element in the same context
>    as its parent element with that relation (in lexical order) will
>    indicate the URI to use as the subject.
> ]]
> 
> Since the order of link relations in atom is insignificant this is 
> breaking the little atom semantics defined.
> 
> Furthermore both the id and the link relations MUST have URIs! So there 
> is absolutely no need to have these default behaviors since RDF has many 
> constructs to make speaking about anything with a URI very easy.
> 
> And even worse than all of the above, the default behavior makes it 
> difficult to speak about the one thing that it may be important to speak 
> about, namely  THE ENTRY (or the feed) ITSELF!!!!
> 
> In Atom Owl every entry is identified by a blank node, which has a 
> functional relation awol:id to an id, and a functional relation 
> awol:updated to a time stamp. It is not easy to speak about individual 
> entries in atom since they don't have identifiers. So the obvious 
> location to put information about them is as children of that element as 
> hinted at by the atom spec in section 6.4.1, which admittedly is about 
> simple extensions, but nevertheless makes the point well
> 
> [[
> The element can be interpreted as a simple property (or name/value pair) 
> of the parent element that encloses it. The pair consisting of the 
> namespace-URI of the element and the local name of the element can be 
> interpreted as the name of the property. The character data content of 
> the element can be interpreted as the value of the property. If the 
> element is empty, then the property value can be interpreted as an empty 
> string.
> ]]
> 
> 
> 5. the mapping section
> ----------------------
> 
> The mapping section that allows one to make ad hoc mappings from atom 
> elements to rdf relations is broken in two ways.
> 
> Take the examples:
> 
> [[
>    <at:map
>     property="http://purl.org/dc/elements/1.1/title">atom:title</at:map>
> 
>    indicates that the atom:title element's content should be mapped to
>    the http://purl.org/dc/elements/1.1/title property.  Given the entry
> 
>    <atom:entry>
>     <atom:id>http://example.com/a</atom:id>
>     <atom:title>Test</atom:title>
>    </atom:entry>
> 
>    and the map above as a child of at:entrymap, the following triple
>    would be implied;
> 
>  <http://example.com/a> <http://purl.org/dc/elements/1.1/title> "Test" .
> 
> ]]
> 
> 
>     5.1 Wrong place to put the mapping
>     - - - - - - - - - - - - - - - - - -
> 
>  It is the wrong way to put these mappings. Much better would be to 
> create a general semantics of atom, and then use RDF semantics to create 
> these mappings. So for example it would be easy to add the following to 
> atom owl
> 
> @prefix dc: <http://purl.org/dc/elements/1.1/> .
> @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
> @prefix awol: <http://bblfish.net/work/atom-owl/2006-06-06/#> .
> 
> awol:title rdfs:subPropertyOf dc:title .
> 
> Why add it every time to the atom document? Is this something that you 
> think is going to be changing from one atom feed to another?
> 
> 
>      5.2 the semantics are wrong
>      - - - - - - - - - - - - - -
> 
> 
> After a lot of work the AtomOwl group have come to develop an semantics 
> for atom expressed in RDF. David Powell developed independently an 
> ontology that was shown to be mostly isomorphic. Both would agree on the 
> following: since atom allows two entries to have the same id, one should 
> *not* make the subject of the title relations be the id URI. The 
> following feed is valid atom
> 
> 
> <atom:feed>
>   ...
>   <atom:entry>
>    <atom:id>http://example.com/a</atom:id>
>    <atom:title>Gold increases</atom:title>
>    <atom:updated>2008-06-13T18:30:02Z</updated>
>    <atom:content>The price of gold has just gone up</atom:content>
>   </atom:entry>
> 
>   <atom:entry>
>    <atom:id>http://example.com/a</atom:id>
>    <atom:title>Gold value rises</atom:title>
>    <updated>2008-06-14T02:30:02Z</updated>
>    <atom:content>The price of gold has just gone up by 20%</atom:content>
>   </atom:entry>
>  ...
> </feed>
> 
> if the suggested mapping were right then the meaning of this would be
> 
> [] a awol:Feed;
>   awol:entry <http://example.com/a> .
> 
> <http://example.com/a> dc:title "Gold increases", "Gold value rises" .
>            awol:content "The price of gold has just gone up by 20%",
>                         "The price of gold has just gone up" ;
>            awol:updated "2008-06-13T18:30:02Z"^^xsd:dateTime,
>                         "2008-06-14T02:30:02Z"^^xsd:dateTime .
> 
> 
> which would make it impossible to work out:
>     - which title goes with which content
>     - which title goes with which time stamp
>     - which time stamp goes with which content
> 
> 
> yet that information is very clear in the atom document, and can 
> furthermore be very clearly expressed in rdf without ambiguity, (but 
> with some simplification) as:
> 
> 
> @prefix : <http://bblfish.net/work/atom-owl/2006-06-06/#> .
> @prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
> 
> [] a :Feed;
>    :entry [
>        :id "http://example.com/a"^^xsd:anyURI;
>        :title "Gold Increases";
>        :updated "2008-06-13T18:30:02Z"^^xsd:anyURI;
>        :content "The Price of gold has just gone up";
>        ];
>    :entry [
>        :id "http://example.com/a"^^xsd:anyURI;
>        :title "Gold value rises";
>        :updated "2008-06-14T02:30:02Z"^^xsd:anyURI;
>        :content "The price of gold has just gone up by 20%";
>        ]
> .
> 
> Notice how we can very well associate which title goes with which entry, 
> which updated time stamp, and which content.
> 
> The current Atom Triples spec would make force the wrong default 
> interpretation of atom.
> 
> 
> Given the above I do have to come to the conclusion that the above spec 
> is badly broken. I would suggest first working on an official semantics 
> for atom, then working on a better way to add general extensions to it 
> that would work well with the semantics. This would be useful in getting 
> a general semantics together and on making sure the extensions were 
> meaningful.
> 
> 
> Yours sincerely,
> 
>     Henry Story
> 
> 
> 
> 
> On 1 Jul 2008, at 21:29, Dave Beckett wrote:
>> Mark Nottingham and myself have co-authored an internet draft for
>> transporting RDF in Atom.  We've called it "Atom Triples" since
>> the focus is on Atom, annotating/adding the triples to the existing
>> format.  Where we had a choice of the atom way or the rdf way, we
>> picked the atom way.
>>
>> So the purpose of this format is to allow adding of triples for
>> descriptions of the resources in an atom feed, using the URI
>> of one atom:link as the main resource.  The body of the at:md
>> is typically the blank-node-closure of the graph associated with
>> the main resource.  Or at least, that's how I've done it so far.
>>
>> This is Version 0 and we know there are some things in the example
>> that need clarifying and expanding and other questions, but here it is:
>>
>> AtomTriples: Embedding RDF Statements in Atom
>> http://www.ietf.org/internet-drafts/draft-nottingham-atomtriples-00.txt
>>
>> Usual IETF I-D caveat: this URL will expire.
>>
>> Dave
>> & Mark
>

Received on Wednesday, 2 July 2008 15:47:57 UTC