Pete, everyone,
I really think this is ready for public comment.
Pete, are you in a position to turn this into a HTML document and start
the process towards public comment?
/Mikael
lör 2007-08-04 klockan 23:03 +0100 skrev Pete Johnston:
> The current DCMI Recommendation, Expressing Dublin Core in HTML/XHTML
> meta and link elements [1], preceded the development of the DCMI
> Abstract Model, and so is not based on the DCAM description model.
>
> I've had a go at drafting a new document which specifies a mapping of (a
> subset of) the DCAM description model to HTML/XHTML meta and link
> elements i.e an X/HTML metadata profile for encoding DC metadata in
> X/HTML which is based on the DCAM. See
>
> http://dublincore.org/architecturewiki/DCXHTMLGuidelines/2007-07-27
>
> A few things to note:
>
> (i) this is an X/HTML metadata profile (See [2]). I'm suggesting we use
> a different profile URI for this profile from that used for the profile
> defined by the current recommendation. I _think_ that would be the right
> thing to do so that it is explicit that an instance is to be interpreted
> in this way, but I could probably be persuaded that it isn't necessary!
>
> (ii) this profile supports only a subset of the DCAM description model.
>
> (iii) statements with a literal value surrogate are represented using
> X/HTML meta elements, and statements with a non-literal value surrogate
> are represented using X/HTML link elements. The scheme attribute is
> available only on the meta element, and so is to be used only for the
> encoding of syntax encoding scheme URIs, not vocabulary encoding scheme
> URIs. i.eThe profile does _not_ support the encoding of vocabulary
> encoding scheme URIs.
>
> (iv) this profile does not suppport the "double name" convention in the
> prefixed name i.e. the property URI http://purl.org/dc/terms/created
> must be represented as a prefixed name like "dcterms.created", not
> "dc.date.created".
>
> (v) I've suggested using the title attribute of the link element to
> encode a single value string within a non-literal value surrogate. I'm
> not sure whether this is too much of a stretch of the way X/HTML defines
> that attribute. If it is, then I think we'd probably have to exclude
> value strings within non-literal value surrogates from the subset of the
> model that is supported.
>
> DC-HTML & GRDDL
> ===============
>
> There's an XSLT transform which maps this profile to RDF/XML i.e.
> supports GRDDL [3] for this profile
>
> http://www.incognitum.net/petej/projects/dc-html/xslt/2007/08/02/dc-html
> 2rdfxml.xsl
>
> And a small set of examples
>
> http://www.incognitum.net/petej/projects/dc-html/xhtml/2007/08/02/
>
> I've used a www.incognitum.net URI
>
> http://www.incognitum.net/petej/projects/dc-html/2007/08/02/
>
> for the profile URI in those documents, in order to provide access to
> the transform for a GRDDL processor for those examples, but if this was
> adopted the profile URI would be a DCMI-owned URI.
>
> DC-HTML & eRDF
> ==============
>
> Like the profile defined by the existing recommendation, this profile is
> compatible with the Embeddable/Embedded RDF profile (eRDF) defined by
> Ian Davis of Talis. See
>
> http://purl.org/NET/erdf/profile
>
> I think Ian chose the conventions for eRDF with the intent of making
> that profile compatible with the existing DCMI recommendation.
>
> The suggested profile differs from eRDF in (I think) four ways:
>
> (i) it doesn't define any conventions for DC metadata within the body of
> the X/HTML document.
>
> (ii) it has "built-in knowledge" of the DC and DCTERMS prefixes i.e.
> "prefixed names" using those prefixes will be mapped to
> http://purl.org/dc/elements/1.1/... and http://purl.org/dc/terms/...
> URIs even in the absence of a "namespace declaration" (link
> rel="schema.DC" href="....") (I'd be happy to drop this and make it a
> requirement to provide a "namespace declaration").
>
> (iii) the value of the scheme attribute of the meta element is mapped to
> the URI of the datatype of the literal object.
>
> (iv) the title attribute of the link element is mapped to an additional
> triple with an rdf:value predicate. (As I say above, this might be a
> stretch!)
>
> So the results of
>
> XHTML -> DCAM --> RDF
>
> would be consistent with
>
> XHTML -> RDF
>
> via the eRDF profile, though the former would generate some additional
> triples.
>
> DC-HTML & RDFa
> ==============
>
> What this new draft _doesn't_ address is any RDFa [4] interpretation of
> an XHTML 1.0/1.1 doc using this profile.
>
> I must admit I'm still a bit unclear about how RDFa applies to XHTML
> 1.0/1.1 docs. But my understanding (and I could be wrong about this!) is
> that RDFa will not be defined as an X/HTML metadata profile, so there
> will not be a profile URI for RDFa. However - at least in XHTML 1.1 -
> there will be some other "hook"/"trigger" to signal that an XHTML 1.1
> doc contains RDFa - a reference to a specific DTD in the DocType
> declaration, I think?
>
> If I'm wrong about that, and if an RDFa processor _is_ going to extract
> triples from an XHTML 1.0/1.1 doc regardless, then, given that RDFa uses
> a QName-like convention based on XML Namespaces for representing URIs,
> and this profile (and eRDF) uses a different convention, I'd expect an
> RDFa processor to generate some rather nonsensical triples e.g. given
>
> <meta name="dc.title" content="My title" />
> <link rel="dc.creator" href="http://example.org/Fred" />
> <link rel="schema.dc" href="http://purl.org/dc/elements/1.1/" />
>
> a GRDDL processor using the dc-html profile transform would generate
>
> <> dc:title "My title" .
> <> dc:creator <http://example.org/Fred> .
>
> but an RDFa processor would generate (I think?)
>
> <> <http://www.w3.org/1999/xhtmldc.creator> <http://example.org/Fred> .
> <> <http://www.w3.org/1999/xhtmlschema.dc>
> <http://purl.org/dc/elements/1.1/> .
>
> (I think the meta element would be ignored because RDFa uses a different
> attribute for the predicate URI.)
>
> But I'm hoping that my concern here is without foundation, and an RDFa
> processor _does_ need some hook before it goes to work on an XHTML
> 1.0/1.1 doc, and so it will _not_ generate those spurious triples.
>
> But I suppose this begs the larger question of whether DCMI should
> recommend shifting from this current approach (an X/HTML metadata
> profile compatible with the eRDF profile and accessible to a GRDDL
> processor) to an explicitly RDFa-based approach.
>
> Given that RDFa is still under development at this point in time, I'm
> hesitant to recommend that change right now, and I think there is
> considerable value in a GRDDL-able profile.
>
> But at some point in the future once RDFa is done, it may be worth
> producing a separate note on encoding DC metadata using RDFa.
>
> Anyway, comments on any aspect of this welcome - though I'm on leave for
> a week, so I won't be replying for a few days ;-)
>
> Cheers
>
> Pete
>
> [1] http://dublincore.org/documents/dcq-html/
> [2] http://www.w3.org/TR/REC-html40/struct/global.html#profiles
> [3] http://www.w3.org/TR/2007/PR-grddl-20070716/
> [4] http://www.w3.org/TR/2007/WD-xhtml-rdfa-primer-20070312/
>
>
> ---
> Pete Johnston
> Technical Researcher, Eduserv Foundation
> Web: http://www.eduserv.org.uk/foundation/people/petejohnston/
> Weblog: http://efoundations.typepad.com/efoundations/
> Email: [log in to unmask]
> Tel: +44 (0)1225 474323
>
--
<[log in to unmask]>
Plus ça change, plus c'est la même chose
|