Extensions and Extension Attributes
flag
6 messages - Collapse all
/groups/adfetch?adid=y8Fj2BIAAAAeYta7v1LSvyKsGngN8-Boh5lxlfRIbyc9A2ECkYtVyg
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
1.  Elias Torres  
View profile  
 More options Jul 13 2006, 10:38 am
From: Elias Torres <el...@torrez.us>
Date: Thu, 13 Jul 2006 10:38:15 -0400
Local: Thurs, Jul 13 2006 10:38 am
Subject: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author
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.

Our store doesn't capture in RDF elements containing extension
attributes so yesterday we started climbing this hill in our trek to
Atom/OWL mountain. Ben Szekely, Lee and I were discussing how do we want
to model extensions in a way that was not as structured as Powell's
approach and came up with some good ideas.

Here's the problem child #1:

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

Here's another problem child #2:

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

#1 is not that bad:

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

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

#2 is where the hill got a little steep:

[] :id "urn:lsid:ex.org:entries:1"^^xsd:anyURI .

However, Lee remembered to check the hiking module and found this gem:

http://www.w3.org/TR/rdf-schema/#ch_value

"""rdf:value is an instance of rdf:Property that may be used in
describing structured values."""

There's a note to see example 16 in the RDF primer, but that's not
right. Instead you must go to Section 4.4

http://www.w3.org/TR/2004/REC-rdf-primer-20040210/#rdfvalue

"""in some cases one of the parts of the structured value is often
thought of as the "main" value, with the other parts of the relation
providing additional contextual or other information that qualifies the
main value."""

The most relevant line: "...or other information that qualifies the main
value..."

[] :id [
    rdf:value "urn:lsid:ex.org:entries:1"^^xsd:anyURI

    # other contextual information..
] .

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" .
] .

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.

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 .
]

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 .

Regards,

Ben, Lee and I.


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
2.  Henry Story  
View profile  
 More options Jul 13 2006, 1:18 pm
From: Henry Story <henry.st...@bblfish.net>
Date: Thu, 13 Jul 2006 19:18:37 +0200
Local: Thurs, Jul 13 2006 1:18 pm
Subject: Re: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author
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.

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.

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.

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 .

[] :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.

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

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).


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
3.  Elias Torres  
View profile  
 More options Jul 13 2006, 4:58 pm
From: Elias Torres <el...@torrez.us>
Date: Thu, 13 Jul 2006 16:58:17 -0400
Local: Thurs, Jul 13 2006 4:58 pm
Subject: Re: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author

As real as it gets.

http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-thread-1...

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.

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

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


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
4.  Henry Story  
View profile  
 More options Jul 15 2006, 1:11 pm
From: Henry Story <henry.st...@bblfish.net>
Date: Sat, 15 Jul 2006 19:11:01 +0200
Local: Sat, Jul 15 2006 1:11 pm
Subject: Re: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author
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:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
5.  Henry Story  
View profile  
 More options Jul 16 2006, 3:46 am
From: Henry Story <henry.st...@bblfish.net>
Date: Sun, 16 Jul 2006 09:46:07 +0200
Local: Sun, Jul 16 2006 3:46 am
Subject: Re: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author
Well thinking about this a little more I found a solution  to the  
namespace mismatch problem: Invent a simple awol uri.

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:


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
6.  Henry Story  
View profile  
 More options Jul 18 2006, 9:06 am
From: Henry Story <henry.st...@bblfish.net>
Date: Tue, 18 Jul 2006 15:06:55 +0200
Local: Tues, Jul 18 2006 9:06 am
Subject: Re: Extensions and Extension Attributes
Print | Individual message | Show original | Report this message | Find messages by this author
And if you want a theoretical explanation here is a sketch of one.

let us define two rdf relations

    :ElementOrAttribute a owl:Class;
    rdfs:comment "the things that group together names and attributes  
in xml. There is a name probably, need to look it up. Is it QName?"@en .

    :namespace a owl:ObjectProperty;
         rdfs:domain :ElementOrAttribute;
         rdfs:range xsd:anyUri;
        rdfs:comment "The namespace uri for the attribute. For atom xml this  
is 'http://www.w3.org/2005/Atom'. We need to create a default uri for  
attributes or elements without namespaces."@en.

    :name a owl:DatatypeProperty;
         rdfs:domain :ElementOrAttribute;
         rdfs:range xsd:string;
        rdfs:comment "the name of an xml element or attribute. So for  
atom:entry the name is 'entry'"@en .

     [] cifp:productProperty ( :namespace :name );
        a owl:InverseFunctionalProperty .

So we can describe every xml element and attribute with the above  
vocab. Eg atom:entry is

    _:ae :namespace "http://www.w3.org/2005/Atom"^^xsd:anyUri;
         :name "entry" .

   Now I suppose we need a vocabulary to map those things to rdf things.

   :xml2rdf a owl:ObjectProperty;
            rdfs:domain :ElementOrAttribute;
            rdfs:range webarch:InformationResource;
            rdfs:comment "a property that maps xml syntax elements to  
their rdf meaning"@en.

   then we can write

  _:ae :xml2rdf :entry .

   So in particular for thr:count we can write

   [] :namespace "http://purl.org/syndication/thread/1.0"^^xsd:anyUri;
      :name "count";
      :xml2rdf <http://bblfish.net/work/atom-owl/2006-06-06/ext/
http://purl.org/syndication/thread/1.0#count> .

This probably needs some more work, but it looks mostly right.

Henry

[1] On namespace defaulting see also <http://www.w3.org/TR/REC-xml-
names/#defaulting> .

On 16 Jul 2006, at 09:46, Henry Story wrote:

...

read more »


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.

Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2012 Google