> One major problem with mapping any extensions from xml to rdf has to
> do with the "semantic gap" between xml namespaces and rdf names. xml
> namespaces are sadly enough *not* uris. It is only an rdf/xml
> interpretation to interpret all elements and attributes as referring
> to urls. This shows up in a number of ways.

> The atom namespace for example is: "http://www.w3.org/2005/Atom"
> atom:title transformed to a url would be http://www.w3.org/2005/
> Atomtitle,
> which is a uri, but not really the type we would give the title
> attribute in rdf where we would have chosen
> the http://www.w3.org/2005/Atom# or http://www.w3.org/2005/Atom/
> prefixes. Since those namespaces say nothing about uris we cannot
> assume that we can make those uris up that way.

> So for example for the thread link extension, we cannot really just
> assume that thr:count can be turned into a url by simply appending
> "count" to the namespace, as that would give us the url

> <http://purl.org/syndication/thread/1.0count>

> So my thinking is that we should deal with each extension on an case
> by case basis. If we can interpret them we can transform them to rdf,
> otherwise we will just have to carry them around as strings. So for
> the link example

> <a:link rel="replies" href="foo" thr:count="10" xmlns:thr="urn:foo" />

> we will have to use

> [] :link [ a :Link;
>             :rel iana:replies ;
>             :to [ :src <http://example.org/foo>;] ;
>       :extension "thr:count='10'";
>             ];

> Of course as soon as we have an interpreter for this extension, (a
> reasonably easy thing to do in this case)
> we will be able to agree that the rdf for the link is

> [] :link [ a :Link;
>             :rel iana:replies ;
>             :to [ thread:count 10;
>                   :src <http://example.org/foo>;] ;
>             ];

> This is ugly of course. We need to create a special url for
> thread:count, unless the spec writers can agree to one in advance.
> But it is the problem inherent in creating a format with no clean
> semantics, the way the atom xml has been designed. Luckily, since
> atom has no clear semantics, it will be very difficult for extensions
> to be developed that will make any sense. The atom working group will
> always end up being a huge bottleneck, since extensions that don't
> really get approved by that group will not be understood in any clear
> manner. So keeping track of extensions and giving them
> interpretations should not be such a lot of work.

> Of course people dealing with xml databases will find it much easier
> to work with atom (atom xml is really designed for
> them), since all they will need to do is store the xml file and then
> query it with xquery. If new elements are not understood they don't
> care. If they later need to make some behavior adapted to the new xml
> they will have all the information already available in their  
> database.

> Of course people with xml databases will find it very unpleasant to
> deal with rdf graphs, even when they are in xml, as those graphs
> (unless they have been studiously given the shape of a tree like
> RSS1.0 and RSS 1.1 did) will not be very amenable to xquery
> questioning. Also any data not in the format of a stable xml tree,
> will be completely opaque to those tools. So don't be surprised if
> xml database vendors try to make all data take the shape of a tree.
> Their whole life depends on it.

> Henry Story

> On 13 Jul 2006, at 22:58, Elias Torres wrote:
>> Henry Story wrote:
>>> On 13 Jul 2006, at 16:38, Elias Torres wrote:
>>>> As you already know we are putting the final touches on the Atom/
>>>> RDF
>>>> store and as we work with James Snell from Abdera and author of  
>>>> many
>>>> extensions, he found a "bug" as we don't support extension
>>>> attributes.

>>> This is exactly the right time to start playing with extensions. I
>>> have not tried at all yet.
>>> (in part because it seems like the most clearly badly designed part
>>> of atom - and the thought of all
>>> this wasted time because ... ok I'll stop the rant right here.)

>>>> [snip]
>>>> <a:link rel="replies" href="foo" thr:count="10"
>>>> xmlns:thr="urn:foo" />

>>>> #1 is not that bad:

>>>>  :link [ a :Link;
>>>>            :rel iana:alternate ;
>>>>            :to [ :src <http://example.org/>;] ;

>>>>           thr:count "10"; # notice JS extension
>>>>            ];

>>> is thr:count a real extension btw? Do we have good examples for
>>> this?  You probably by now have a list of good extensions.

>> As real as it gets.

>> http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-
>> thread-12.txt

>>> I suppose in the end we will never be able to formulate a general
>>> rule to know if people put extension there if the extension is meant
>>> to go on the :Link object or on the :Content object it points to.

>>> By the way this could be an argument for making Link just simply
>>> opaque so that all :Link objects always appear like
>>> this

>>> :link [ a :Link;
>>>          :href <http://eg.com/e1.html>;
>>>          :rel iana:alternate;
>>>          :type "text/html";
>>>          thr:count "10";
>>>        ] .

>>> here we would be very close to the syntax.

>> Sure.

>>> Of course having something that simplifies things the way we have  
>>> now
>>> is really nice too. But I am worried that we may be trying to  
>>> improve
>>> atom.

>> Not me.

>>> So keep this in mind as you work with extensions.

>>>> #2 is where the hill got a little steep:

>>> reminder to myself: we are dealing with this example:

>>> <a:id xmlns:x="urn:bar"
>>> x:identifierType="lsid">urn:lsid:ex.org:entries:1</a>

>>>> [snip]
>>>> Now we can go into the extension attributes...

>>>> [] :id [
>>>>     rdf:value "urn:lsid:ex.org:entries:1"^^xsd:anyURI
>>>>     x:identifierType "lsid" ;
>>>>     random:property  "randomValue" .
>>>> ] .

>>> By the way I wonder how this compares to using owl:sameAs .

>> Nothing that I read mentioned owl:sameAs .

>> http://esw.w3.org/topic/InterpretationProperties

>> http://www.w3.org/DesignIssues/InterpretationProperties

>> http://chatlogs.planetrdf.com/rdfig/2003-03-26.html#T18-31-10

>>> [] :id [ owl:sameAs "urn:lsid:ex.org:entries:1"^^xsd:anyURI;
>>>           x:identifierType "lsid" ;
>>>           random:property  "randomValue" ] .

>>>> x:identifierType rdfs:type atom:extensionAttributeProperty;
>>>> atom:extensionAttributeProperty rdfs:subClassOf rdf:Property .

>>>> Now because of atom:extensionAttributeProperty we can figure what
>>>> extension attributes to attach back to the original element.

>>> ok.

>>>> Now onto extensions.

>>>> atom:extension rdfs:type atom:extensionElementProperty;

>>>> <a:entry>
>>>> <gd:when startTime="2005-06-06" endTime="2005-06-07"
>>>>        valueString="This weekend"/>
>>>> </a:entry>

>>>> [ :extension "<gd:when startTime="2005-06-06" endTime="2005-06-07"
>>>>        valueString="This weekend" xmlns:gd="http://schemas.google.com/g/
>>>> 2005"
>>>> />"^^rdf:XMLLiteral .
>>>> ]

>>> Yes. I agree. This is what one has to do, unless one is given some
>>> indication as to the meaning of the extension.
>>> In which case one could process it and extract the meaning as a set
>>> of tri

>>>> Luckily, the only two things we need to pass to extension elements:
>>>> xml:lang and xml:base and those can easily be added (unless
>>>> there's a
>>>> conflict, but that's another hill to climb and we're not there yet
>>>> since
>>>> we can only climb on hill at a time).

>>>> Now in case someone brings up the I would like to query the name of
>>>> the
>>>> extension (local and/or ns) etc, I would like to push that off to
>>>> SPARQL
>>>> and a XPath extension against the XMLLiteral.

>>>> Additionally, we could support :simpleExtension.

>>>> <a:entry>
>>>> <s:when>Today</s:when>
>>>> </a:entry>

>>>> [
>>>>    s:when "Today" .
>>>> ] .

>>>> s:when rdf:type atom:simpleExtensionElementProperty .
>>>> atom:simpleExtensionElementProperty rdfs:subClassOf rdf:Property .

>>> Yes. That looks good.

>>>> Regards,

>>> Looks like a really good start. Would you like to write up a little
>>> section for the html version explaining this? Perhaps a little
>>> further down the road when things have settled a bit (or before to
>>> help you think about them).

>> k. We'll get to that bridge when we get there. ;)

>>>> Ben, Lee and I.