> So to take the thread example

> <a:link rel="replies" href="foo" thr:count="10" xmlns:thr="http://
> purl.org/syndication/thread/1.0" />

> we can find a url for thr:count by construction quite simply:

> http://bblfish.net/work/atom-owl/2006-06-06/ext/http://purl.org/
> syndication/thread/1.0/count

> We can then create our own prefix

> @prefix thr: <http://bblfish.net/work/atom-owl/2006-06-06/ext/http://
> purl.org/syndication/thread/1.0#> .

> And then we too can write, without fear of trading on someone's toes

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

> If these spec writers ever decide on an official rdf url for their
> attributes, we can always map our constructed
> attributes to theirs using owl:sameAs

> thr:coundt owl:sameAs thread:count .

> So the trick is to find a good construction mechanism. It would be
> very nice if such a construction mechanism on dereferenceing would
> return a cgi generated web page explaining the meaning of the
> construction.

> Henry

> On 15 Jul 2006, at 19:11, Henry Story wrote:
>> 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.