Re: DC vs. DCTERMS in initial context

I agree with Gregg. The initial context isn't there so that people can
blindly drop their prefix definitions. When converting from 1.0 to 1.1, one
should convert the xmlns to the @prefix notation. Dropping the prefix
definitions and relying on the initial context is optional. If there is a
desire to do so, care should be taken when converting old markup: first
make sure the old prefix definitions match the initial context, and then
make sure also that all of the prefix definitions are present in the
context. IMO it is less work with systematically convert prefix defintions
to the new @prefix syntax and sticking with it.

Steph.

On Fri, Aug 31, 2012 at 9:55 AM, Gregg Kellogg <gregg@greggkellogg.net>wrote:

> On Aug 31, 2012, at 4:09 AM, "Oskar Welzl" <lists@welzl.info> wrote:
>
> >
> >> As far as I remember, the advice of DCMI (Tom, correct me if I am
> >> wrong) was to use only /dc/terms in future, [...]
> >> Personally, I would like to defer the choice to DCMI.
> >
> > The choice to prefer DCTerms for current/future use is one thing.
> >
> > The problem arises when you change existing RDFa to RDFa 1.1 and rely on
> > the initial context. In this case, the RDF output doesn't comply to the
> > DCMI recommendations. I came across this when I tried to convert the
> > RDFa 1.0 example in wikipedia [1] to RDFa 1.1, removing XML namespace
> > declarations while doing so.
> >
> > I expected the same RDF triples thanks to the initial context, but got
> >
> > <http://example.org/john-d/>
> >    <http://purl.org/dc/terms/creator> "Jonathan Doe"@en;
> >
> > instead of the original
> > <http://example.org/john-d/>
> >    <http://purl.org/dc/elements/1.1/creator> "Jonathan Doe"@en;
> >
> > Now dc:creator (or http://purl.org/dc/elements/1.1/creator) may be used
> > with literals, so the original RDFa 1.0 was OK.
> > OTOH, dcterms:creator, according to the user guide [2], must not be used
> > with literals. I had overrule the initial context and insert the
> > corresponding prefix into the HTML+RDFa 1.1 example to make it work.
> >
> > I don't know how many will change from existing markup to 1.1, but if
> > they do there'll be some more unwanted literals as dcterms:creators out
> > there.
> >
> > Maybe it'd be enough to point this out somewhere. I have no idea how
> > relevant it will become.
>
> One purpose of the initial context is as a fallback mechanism, in case a
> document is authored accidentally without appropriate prefix definitions.
> For example, this made many documents using OGP valid RDFa again.
>
> We had considered that a best practice would be for authors to not rely on
> prefixes defined in the initial context and recommend that authors define
> their own @prefix definitions. The initial context is a convenience method
> which doesn't replace the need for authors with specific vocabulary needs
> from being explicit. As new use of DCMI should use dc/terms anyway,
> providing a convenience mechanism makes sense, IMO.
>
> Gregg
>
> > Cheers
> > Oskar
> >
> > [1] http://en.wikipedia.org/wiki/RDFa#XHTML.2BRDFa_1.0_example
> > [2]
> >
> http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata#dcterms:creator
> >
> >
> >> Cheer
> >>
> >> Ivan
> >>
> >> On Aug 29, 2012, at 20:42 , Oskar Welzl wrote:
> >>
> >>> I only noticed a few day ago that both dc: and dcterms: are used for
> >>> http://purl.org/dc/terms/
> >>> in the initial context. In most examples or practical uses so far, I've
> >>> seen dc: being used for
> >>> http://purl.org/dc/elements/1.1/
> >>> instead, making it easy to distinguish between the legacy vocabulary
> and
> >>> DCTerms. (Practical example:
> >>> http://wiki.dublincore.org/index.php/User_Guide/Publishing_Metadata)
> >>>
> >>>
> >>> What's the rationale behind this decision in the initial context?
> >>>
> >>> Oskar
> >>>
> >>>
> >>
> >>
> >> ----
> >> Ivan Herman, W3C Semantic Web Activity Lead
> >> Home: http://www.w3.org/People/Ivan/
> >> mobile: +31-641044153
> >> FOAF: http://www.ivan-herman.net/foaf.rdf
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
>

Received on Friday, 31 August 2012 14:05:48 UTC