On the subject of the LANG attribute where SCHEME is "URL", my own preference is
to stick to a "purist" perspective of using HTML elements the way they were
designed to be used. If a document is available through language negotiation
between the browser and the server, the easiest way of handling that is to behave
as if the document was available in any (or no) language - simply have no LANG
attribute for a SCHEME of "URL".
If a document is available in multiple languages, then the DC.Language field for
that document's metadata should be repeated for each language the document is
available in. We *will* need to think up a way of expressing documents that are
available translated into every language (either as pre-translated pages, or
translated on-the-fly by some robot).
The browser/server language negotiation for the resource document takes place at
the time of resource access, not resource discovery. It's up to the meta data
indexing engine to find what languages the resource is available in. Which
implies it's up to the meta data creator to define what those languages are.
[pause to take a breath]
When it comes to the DC.Rights field itself (regardless of the use of the LANG
attribute), can't we just say that if the SCHEME is URL (or URI or whatever),
then the CONTENT is a pointer to the Rights statement, which is a document
itself?
Yes, adding DC metadata to the Rights statement will be cumbersome (but then,
isn't that true of ANY document you add metadata to?). IMHO, it's the "right"
thing to do. If we're going to expect our computers to pretend to be smart in
fetching us information, we have to be pedantic about showing them how to find
it. In the RDF version, we'll probably end up having people nesting the metadata
for the Rights statement - which IMHO is the wrong way to do things, since you're
duplicating information every time you reference the Rights statement. This means
much more work in the event that you change the language(s) that the Rights
statement is available in.
What if someone goes out there and wants to find documents along the lines of
"rights <IN> DC.Subject" ? Perhaps an author wants to find out how other people
protect their intellectual property. Or an inventor is looking for ways of
advertising a new invention, without negating the patent (since publication of an
invention or technique can prevent a patent from being issued). Heck, maybe
you're a lawyer trying to prepare a defence in a rights-violation case, and you
want to compare the prosecutor's Rights statement to current "best practice" or
strategic precedents.
The company that writes the Rights document may use it as a linking point to
their Intellectual Property division, their Innovations division, and perhaps
their Public Relations division. So now the Rights statement has ceased to be a
simple "field filler", and is a real, viable document in its own right. The
DC.Rights field for the Rights statement might point to the document itelf, or
contain just a short textual comment to the effect of "This document copyright
© 1998, MyCo".
Who are we, as mere document classifiers, to decide what is and what isn't a
useful source of information for any researcher out there?
Regards,
Alex Satrapa
Misha Wolf wrote:
> Titia van der Werf wrote:
>
> This attribute specifies the base language of an element's attribute
> values and text content. The default value of this attribute is unknown.
>
> What Titia is asking for is provided by the [HREFLANG] attribute:
>
> This attribute specifies the base language of the resource designated by
> href and may only be used when href is specified.
>
> This attribute is, regrettably, unavailable with the META element. We could
> ask for it to be added, but I'm not sure it's worth it, with RDF almost
> ready.
>
> In any case, I don't think this is the right way to do language versions.
> HTTP provides language negotiation, which is supported by most browsers.
> I think you should have just one, generic, URI and rely on HTTP language
> negotiation to select the right language version.
|
