Re: Atom/RDF XSLT and GRDDL

I did some work some time ago relating AtomOwl with AtomRDF.

http://groups.google.com/group/atom-owl/browse_thread/thread/ 
906cdb0196aee68

I think this shows really that David and my work are really close,  
which serves
to confirm each other's work.

I myself share Danny's worry that Atom's extensibility is not  
serious. It is extensible
but every extension will need to be dealt with seperately. The way to  
deal with
this would seem to me to lie in extending the GRDDL rather than in  
trying to
add opaque strings to an RDF database... In any case it is going to  
be so much
work for people to keep up to date with atom extensions, that my  
guess is that
nothing more that a handful of extensions can really make it.

After having worked on a lot more things in the semantic space, I  
think tidying up
AtomOwl won't be so much of a problem anymore. I tended to get hung  
up on some small
problems.

Henry


On 4 Sep 2007, at 20:29, Danny Ayers wrote:

> On 23/08/07, David Powell <djpowell@djpowell.net> wrote:
>
>> I guess before we get carried away with ourselves, we should be  
>> asking
>> what we want from the vocabulary rather than the what we want from  
>> the
>> transform.
>
> Fair point.
>
>> Personally, I have the following 'wants':
>>
>>  * Round-trippable.  Obviously minor differences are allowed, but
>>    nothing semantically significant should be lost.
>
> I too think this is very desirable, not least because it would mean
> that we'd have a kind of baseline for generation of Atom from other
> RDF systems.
>
>>  * Full support for extension elements.  Simple vs Structured
>>    Extension Elements were designed to support RDF, but what we ended
>>    up with doesn't really help anyone, so I wouldn't pay much
>>    attention to the difference between the two.
>
> If I remember correctly is should be possible to directly support
> Simple Extension elements (as properties of their container element).
> But I'm not sure there's a lot that can be done with Structured
> Extension Elements in general, I believe they're pretty much "anyXML".
>
>>  * Triples shouldn't smush into mush when two feed documents  
>> polled at
>>    different times are combined.
>
> Right. That would pretty much rule out using rss:item directly. I'm
> not sure, can mush be completely avoided without needing extra CIFP
> logic?
>
>>    I think that this is fairly important because of the fact that
>>    feeds are all about changing data, so I think that it is useful to
>>    support merging of feed documents (RSS 1.0 doesn't)
>>
>>  * No expectancy that the software should have to perform any kind of
>>    general purpose inference.
>
> Yep.
>
>>  * Dual OWL/RDFS schema. Is it just me that prefers RDFS? I'm
>>    more of a fan of RDF-the light-weight data model, than RDF-the  
>> heavy
>>    weight stack.
>
> Sounds reasonable. But if we can keep results within OWL DL without
> bending things, I reckon it'd be desirable. I notice the FOAF schema
> uses both owl:Class and rdfs:Class for terms, presumably the OWL
> property types could also appear along with rdf:Property.
>
>>  * Design decisions of vocabulary should all be justified. I've been
>>    meaning to do this to my vocabulary, but haven't got around to it.
>
> Yep, but we need something to build those justifications on -
> maximising interop seems a reasonable if vague goal. (Better
> justification than "I named the terms for my pet hamsters" at
> least...)
>
>>  * It should be possible to represent RSS feeds using the same
>>    vocabulary.  We don't need to think about the transform right now,
>>    and they may require supplementary terms, but it should be doable.
>>    I have added support for major RSS versions to my transform,
>>    although they may still require a bit of work.
>
> Some of the poorly defined pieces of 'simple' RSS, would be
> problematic e.g. what do you do with a 2-digit year? I'd leave this as
> 'roughly doable' :-)
>
>>  * I'd prefer an XSLT 1.0 solution.  XSLT 2.0 doesn't seem as widely
>>    deployed yet.
>
> Yes. The GRDDL spec only really talks in terms of XSLT 1.0 anyhow.
>
> Cheers,
> Danny.
>
> -- 
>
> http://dannyayers.com