W3C home > Mailing lists > Public > public-grddl-comments@w3.org > July to September 2007

Re: Atom/RDF XSLT and GRDDL

From: Danny Ayers <danny.ayers@gmail.com>
Date: Tue, 4 Sep 2007 19:29:45 +0100
Message-ID: <1f2ed5cd0709041129s2fb50bdydcc683693798f2bc@mail.gmail.com>
To: "David Powell" <djpowell@djpowell.net>
Cc: "Story Henry" <henry.story@bblfish.net>, "Dave Beckett" <dave@dajobe.org>, public-grddl-comments@w3.org

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
Received on Tuesday, 4 September 2007 18:29:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:11:43 GMT