RE: Atom Link element: Failure

[Jeremy Gray]

Henry, would you mind sending me a copy of the example you were trying to
work up? I took a scroll through your recent emails to see if I could figure
out which one gave you so much trouble, but I'm not sure if I'm looking at
the right materials or not.

I'm curious because you mention that when there is an "rdf:Resource[sic] you
can't also have 
attributes" which, given that rdf:resource applies only to property
elements, makes sense. As such, I'm wondering what exactly you were trying
to accomplish when you hit your roadblock.

Thanks in advance,

Jeremy 

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Henry Story
Sent: Monday, January 10, 2005 10:12 AM
To: Robert Sayre; Tim Bray
Cc: [EMAIL PROTECTED]; 'Atom WG'
Subject: Re: Atom Link element: Failure



Ok, I give up on this task.

I have just found that when there is a rdf:Resource you can't also have 
attributes. And that attributes have to be qualified.

It is a real pity.

It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 
where this works out fine.

Henry

On 10 Jan 2005, at 01:29, Robert Sayre wrote:
> Henry Story wrote:
>
>> [snip]
>> 4) Property attributes
>> --
>>
>> both hreflang, href and all the other properties of Link are unique,
>> and given that they are string literals (subsets of them at least, 
>> but  nevertheless) they can be move into attributes on Link
>>
>> 
>>>  hreflang="de"
>> href="http://example.org/de/2003/12/13/Atom03"/>
>> 
>
>
> Use of unqualified attributes is deprecated in RDF/XML (check the
> validator). My opinion is that the transformation you're looking for 
> would be easier with XSLT.

You are right. The validator at <http://www.w3.org/RDF/Validator/> is 
really useful.

[snip]

>>>
>>> It gets a POST with a fairly average atom entry, but there are
>>> extensions in funny places. Like most people, the server stores  
>>> standard fields in a relational database, so there are columns for  
>>> title, summary, etc. in a table called something like  
>>> "journal_entries". It would be fairly easy to store immediate 
>>> children  of entry in an "unknown_xml" field, and pass them through, 
>>> but what  about the other extensions? Using an RDF store might make 
>>> this problem  a lot easier, but I don't forsee a mass migration in 
>>> that direction  happening this year or next.
>>
>>
>> You don't need a specialized RDF storage, though very good ones
>> exist.  There are schemes to map RDF into any relational database, 
>> just as  there are schemes to map objects into relational databases. 
>> In fact  most RDF storage tools in Java provide this.
>
>
> That's not my point. My point is that there's a staggering amount of
> data currently living in RDBMSes, and people aren't going to 
> re-architect their storage to use Atom.

I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a little 
care also turn out to be a well engineered RDF document. That would 
provide maximum flexibility in that it would allow people to move into 
the rdf world seamlessly.


> Robert Sayre
>

Re: Atom Link element: Failure

[Henry Story]

Ok, I give up on this task.
I have just found that when there is a rdf:Resource you can't also have 
attributes. And that attributes have to be qualified.

It is a real pity.
It would be good to make a list of what we would have needed from 
RDF/XML to make Atom be rdf, and then work backwards to create RDF/XML2 
where this works out fine.

Henry
On 10 Jan 2005, at 01:29, Robert Sayre wrote:
Henry Story wrote:
[snip]
4) Property attributes
--
both hreflang, href and all the other properties of Link are unique,  
and given that they are string literals (subsets of them at least, 
but  nevertheless) they can be move into attributes on Link


   
 hreflang="de" 
href="http://example.org/de/2003/12/13/Atom03"/>


Use of unqualified attributes is deprecated in RDF/XML (check the 
validator). My opinion is that the transformation you're looking for 
would be easier with XSLT.
You are right. The validator at  is 
really useful.

[snip]
It gets a POST with a fairly average atom entry, but there are  
extensions in funny places. Like most people, the server stores  
standard fields in a relational database, so there are columns for  
title, summary, etc. in a table called something like  
"journal_entries". It would be fairly easy to store immediate 
children  of entry in an "unknown_xml" field, and pass them through, 
but what  about the other extensions? Using an RDF store might make 
this problem  a lot easier, but I don't forsee a mass migration in 
that direction  happening this year or next.

You don't need a specialized RDF storage, though very good ones 
exist.  There are schemes to map RDF into any relational database, 
just as  there are schemes to map objects into relational databases. 
In fact  most RDF storage tools in Java provide this.

That's not my point. My point is that there's a staggering amount of 
data currently living in RDBMSes, and people aren't going to 
re-architect their storage to use Atom.
I was not trying to get people to use RDF databases at the back end. I 
was just hoping that a well engineered XML document would with a little 
care also turn out to be a well engineered RDF document. That would 
provide maximum flexibility in that it would allow people to move into 
the rdf world seamlessly.


Robert Sayre