Loading ...
Sorry, an error occurred while loading the content.

Simple Semantics Resolution - RSS 2.0 Module

Expand Messages
  • Danny Ayers
    Abstract This specification defines the Simple Semantic Resolution (SSR) Module for the RSS 2.0 syndication format. The purpose of SSR is to provide a
    Message 1 of 2 , May 3, 2003
    View Source
    • 0 Attachment
      Abstract
      This specification defines the Simple Semantic Resolution (SSR) Module for
      the RSS 2.0 syndication format. The purpose of SSR is to provide a mechanism
      by which the semantics of an RSS 2.0 document can be unambiguously resolved
      to an RDF model. This is done by declaring the RSS 2.0 file as being an RDF
      representation and provide a mapping between the RSS 2.0 syntax and the RDF
      model. The mapping is declared using XSLT to give an RSS 1.0-based
      representation, this RDF/XML serialization providing anchorage to the RDF
      model.

      Put simply: an element is added to the source RSS 2.0 document which
      declares "this is RDF, and here is the mapping". This has absolutely no
      effect on the interpretation of the document as RSS 2.0 within the bounds of
      that specification, but enables the contents of RSS 2.0 files to be
      considered first class material for the Semantic Web.

      http://purl.org/stuff/ssr

      ----

      Comments appreciated.

      (This is the very first draft, so it's a bit rough ;-)

      Cheers,
      Danny.

      ----

      http://dannyayers.com
    • Sean B. Palmer
      [All: Please trim the CC list if you feel that s appropriate.] ... I think that it would be useful to let the SSR language be used on a wider scale than RSS
      Message 2 of 2 , May 3, 2003
      View Source
      • 0 Attachment
        [All: Please trim the CC list if you feel that's appropriate.]

        > http://purl.org/stuff/ssr
        >
        > Comments appreciated.

        I think that it would be useful to let the "SSR language" be used on a
        wider scale than RSS 2.0 (for example, in RDF, and perhaps RSS 1.0 as
        a module). I use transformations often, and I'd find it useful to be
        able to state which XSLT sheet provides which output for which
        document.

        This would involve slightly--but only slightly--increasing the
        complexity; in particular, allowing more output formats than just RDF,
        and rewording the document to make it more general. The RSS 2.0
        example would only increase in complexity by a single typing
        attribute. I envision something like:-

        RSS 2.0/arbitrary XML:
        <ssr:ssr type="application/rdf+xml"
        transform="http://w3future.com/weblog/gems/rss2rdf.xsl"/>

        (note: only one attribute more is required; doesn't even have to be a
        MIME type; you could have a central repository of string to MIME type
        mappings if "application/rdf+xml"'s registration state scares you).

        RSS 1.0:
        <rdf:Description rdf:about="">
        <ssr:ssr rdf:parseType="Resource">
        <ssr:type>text/html</ssr:type>
        <ssr:transform rdf:resource="http://example.org/rss2html.xsl"/>
        </ssr:ssr>
        </rdf:Description>

        Arbitrary RDF/XML:-
        <rdf:Description rdf:about="somedoc.rdf">
        <ssr:ssr rdf:parseType="Resource">
        <ssr:type>text/html</ssr:type>
        <ssr:transform rdf:resource="http://example.org/rss2html.xsl"/>
        </ssr:ssr>
        <ssr:ssr rdf:parseType="Resource">
        <ssr:type>text/plain</ssr:type>
        <ssr:transform rdf:resource="http://example.org/rss2txt.xsl"/>
        </ssr:ssr>
        </rdf:Description>

        same in Notation3, for those who appreciate something readable
        [duck]:-

        <somedoc.rdf> ssr:ssr
        [ ssr:type "text/html"; ssr:transform
        <http://example.org/rss2html.xsl> ],
        [ ssr:type "text/plain"; ssr:transform
        <http://example.org/rss2txt.xsl> ] .

        Of course, this proposal runs counter to the KISS principle. With
        these sorts of applications, however, it's very difficult to
        implement-when-needed (YAGNI?), since that often involves a
        model/vocabulary change, and evolution-friendly XML applications
        aren't widespread yet...

        Idle musing: perhaps the xml:style discussions need to be raised
        again. The ?xml-stylesheet PI hack seems to have taken its hold,
        though.

        Cheers,

        --
        Sean B. Palmer, <http://purl.org/net/sbp/>
        "phenomicity by the bucketful" - http://miscoranda.com/
      Your message has been successfully submitted and would be delivered to recipients shortly.