Re: [namespaceDocument-8] RDF in HTML: Approaches

On 2002-06-02 5:15, "ext Sean B. Palmer" <sean@mysterylights.com> wrote:

> 
> This is also peripherally related to [nsMediaType-3]. I have published an
> article which attempts to summarize years of discussions over the various
> methods for associating RDF with HTML.
> 
>  http://infomesh.net/2002/rdfinhtml/
>  RDF in HTML: Approaches
>  Sean B. Palmer, 2002-06-02
> 
> It can also be considered a response to the TAG's subissue note [1], and as
> input to the RDF Core WG's faq-html-compliance issue [2].
> 
> Comments and feedback etc. are welcome.

Great summary, Sean.

One approach that was missed, and which perhaps would be reasonably
painless (given the import of the SW and RDF in addition to XHTML)
would be to take an approach similar to 'script' but where XHTML defines
a metadata element with content type ANY, and whether the application
groks the metadata content or not is not an issue insofar as the
XHTML DTD is concerned.

This is very similar to the 'script' element except that metadata is
required to be well-formed XML (see example below).

Thus, the metadata encoding must still be well-formed XML, but the
XHTML validation otherwise ignores it. If you need to validate
the embedded metadata, then you either have to hack the XHTML DTD
to change the ANY content to the root of the metadata model
(e.g. rdf:RDF) or extract the metadata for validation. Either way,
it's a minimal change to XHTML and in the case of RDF does not
pose any extra work to validate since many RDF parsers already
know how to extract the embedded RDF.

I don't see that metadata need be allowed in the body, since one
can make statements using XPath URIs about any content in the
instance, and it increases the complexity of both the XHTML DTD
as well as parsers needing to restrict per-element metadata to
those restricted contexts. This also avoids any need to change
browsers to prevent display of metadata content in the body.

Thus:

...
<!ELEMENT metadata (ANY)>
<!ATTLIST metadata type CDATA #REQUIRED>
...

<html ...
      xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
      xmlns:dc="http://purl.org/dc/elements/1.1/">
<head>
  <title>My Document</title>
  <metadata type="application/rdf+xml">
    <rdf:RDF>
      <rdf:Description rdf:about="http://www.w3.org/">
        <dc:title>"W3C Homepage"</dc:title>
        <dc:creator>
           <ex:Person>
              <ex:firstname>John</ex:firstame>
              <ex:lastname>Doe</ex:lastname>
           </ex:Person>
        </dc:creator>
      </rdf:Description>
    </rdf:RDF>
  </metadata>
</head>
...



Costs: 

* XHTML WG/W3C: add 'metadata' element to XHTML head (no need to update
  when new encodings come along -- they just have to be well formed XML.
  This change can be done once and for all.

* Browsers: none, insofar as presentation is concerned.

* RDF Users: none, if using parser able to extract/validate embedded RDF.

I.e. pretty cheap overall.


Of course, that said, I'm personally a strong advocate of the view
that metadata has no business being embedded in a resource, and am
most in favor of the link based solution. However, I support Sean's
view that it is probably inevitable that we support both linking and
embedding, and for the latter, I think the above would be an optimal
solution (IMMHO).

--

One final point about N3 and NTriples. I think it is *very* important
that we not miss the fact that neither N3 nor NTriples are official,
standardized representations for RDF. They are very useful, and I'm
not saying one should always use RDF/XML in all contexts, but the
reason why we have standards such as XML, XHTML, RDF, etc. is to
maximize the benefit of interchange of information, and the more
variant representations that Web and SW systems must support, the
less portable and more expensive the endeavor.

I would, thus, not like to see any N3 or NTriples used as primary
representations for RDF that are interchanged by real systems.
N3 and NTriples are not standard encodings for interchange. RDF/XML
is. And that's what folks should be using in a global context.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Monday, 3 June 2002 02:42:50 UTC