Re: what are you saying?

Hi Danny,

I'll begin with the end of your post, so that I can set the context for this.

> Address my point please sir, how does the RDFa-aware agent know what
> it is looking at?
>
> If you are suggesting that scraping, based on well-known string is the
> the determinator, then... well actually I think you said that
> earlier..
>
> "No-one else will use these 8-character strings"
>
> Sorry Mark, that breaks the Web.

I'm not sure what you mean by this...what string?


> What I would really appreciate is a clear statement of what works for
> you, what doesn't - seriously, I might well be wrong. Show.

At the moment I'm not suggesting anything. Up until now we've all been
happy with the use of @profile, but on further examination it turns
out to be a bending of the use of @profile, as detailed below. That
doesn't mean that:

  (a) we can't come up with an alternative. I do have a suggestion,
but I'll post that
  separately, or

  (b) we should bend the definition of @profile to accommodate our usage.

But if we go this last route we might have to convince a lot of
people, and anyway, at the very least I think it is worth us
understanding what it is that we are changing before we go that road.

So my point is essentially that I'm not against having an unambiguous
indicator for the presence of RDFa (but please note that we agreed a
long time ago that it would be optional)...I'm merely saying that the
solution we've been working with doesn't stand up under close
scrutiny.

Which brings us to why that is.


> [[
> Interesting comments, but you haven't addressed the main point.
> @profile is defined in HTML and XHTML as being a way to indicate how
> values in <link> and <meta> should be 'interpreted'. For example, if I
> wanted to use Dublin Core values in @rel, I shouldn't do so unless I
> define a @profile value.
> ]]
> Rubbish. Look at the HTML spec on Meta data profiles. It has nothing
> (specifically) to do with link or meta.

By "rubbish" I assume you mean "I don't agree with you"?

Anyway...

I don't really know how to respond, because @profile is so obviously
about link and meta. The section you refer to (called "Meta data
profiles") is itself a sub-section of the META element section...in
other words, @profile is documented slap bang in the middle of META.

The only thing I can think to do here, is to quote chunks of the spec,
which seems a little overblown, but the alternative is to respond to
your "go read the spec" with another "go read the spec", and I don't
think that's a good way to resolve this...it just becomes a fruitless
game of ping-pong.



HTML 4.01

So, in HTML 4.01, Section 7.4.4 [1] on meta data, we find that it is
possible for authors to use META to set metadata about a document, and
that:

  (a) "This specification does not define a set of legal meta data
  properties", and

  (b) "[t]he meaning of a property and the set of legal values for that
  property should be defined in a reference lexicon called a profile".

The full text is here:

===
7.4.4 Meta data

Note. The W3C Resource Description Framework (see [RDF10]) became a
W3C Recommendation in February 1999. RDF allows authors to specify
machine-readable metadata about HTML documents and other
network-accessible resources.

HTML lets authors specify meta data -- information about a document
rather than document content -- in a variety of ways.

For example, to specify the author of a document, one may use the META
element as follows:

<META name="Author" content="Dave Raggett">

The META element specifies a property (here "Author") and assigns a
value to it (here "Dave Raggett").

This specification does not define a set of legal meta data
properties. The meaning of a property and the set of legal values for
that property should be defined in a reference lexicon called a
profile. For example, a profile designed to help search engines index
documents might define properties such as "author", "copyright",
"keywords", etc.
===

In case we're in any doubt as to what this entails, the next
sub-section (entitled "Specifying meta data") [2] describes the two
steps involved in specifying metadata, the first being to declare a
name/value pair, and the second to define a profile that indicates
what the name part means. Here again, is the full text:

===
In general, specifying meta data involves two steps:

   1. Declaring a property and a value for that property. This may be
done in two ways:
         1. From within a document, via the META element.
         2. From outside a document, by linking to meta data via the
LINK element (see
             the section on link types).
   2. Referring to a profile where the property and its legal values
are defined. To
       designate a profile, use the profile attribute of the HEAD element.

Note that since a profile is defined for the HEAD element, the same
profile applies to all META and LINK elements in the document head.
===



LINK

Section 12.3 on LINK [3] doesn't mention profiles, but it links to
section 6.12 [4] which describes 'link types', i.e., the values that
can be placed into @rel and @rev. This section includes the following:

===
Authors may wish to define additional link types not described in this
specification. If they do so, they should use a profile to cite the conventions
used to define the link types. Please see the profile attribute of the HEAD
element for more details.
===

I think it's fair to say that we've established that to get an
interpretation of values used in @rel, @rev or @name, we need to
specify a profile. But you might still argue that @profile has _other_
uses, beyond just defining the meaning of our terms. So let's look at
@profile more closely, and what a "meta data profile" is.



METADATA PROFILES

In the attributes section of HTML 4.01 [5], the profile attribute is
described as being a "named dictionary of meta info".

In the definition of @profile [6] we see that "[t]his attribute
specifies the location of one or more meta data profiles", and are
advised to 'see below' for more details. If we look below in the
section called 'Meta data profiles' [7] we find:

===
The profile attribute of the HEAD specifies the location of a meta data profile.
The value of the profile attribute is a URI. User agents may use this URI in two
ways:

  * As a globally unique name. [snip]

  * As a link. [snip]
===

I've snipped the detail just to draw attention to the fact that the
URI can either be 'well known', or it can be retrieved, but I'll come
back to the detail in a moment. Before I do, I'd like to draw
attention to the example that the spec goes on to give:

===
This example refers to a hypothetical profile that defines useful properties for
document indexing. The properties defined by this profile -- including "author",
"copyright", "keywords", and "date" -- have their values set by subsequent META
declarations.
===

As you can see, the idea is that _regardless_ of what the @profile
value represents ("a globally unique name" or "a link" to be
retrieved), the upshot is that it defines some properties that can be
used in META declarations (a "named dictionary"). The example that
follows, looks like this:

===
<HEAD profile="http://www.acme.com/profiles/core">
  <TITLE>How to complete Memorandum cover sheets</TITLE>
  <META name="author" content="John Doe">
  <META name="copyright" content="&copy; 1997 Acme Corp.">
  <META name="keywords" content="corporate,guidelines,cataloging">
  <META name="date" content="1994-11-06T08:49:37+00:00">
 </HEAD>
===

As you can see, profiles have *everything* to do with link and meta.



THE SNIPPED BITS

Finally, what about the prose I 'snipped' from the section that began
"[u]ser agents may use this URI in two ways"? (I did it to highlight
the two ways that the value in @profile could be used.) The first
'snip' looks like this, in full:

===
As a globally unique name. User agents may be able to recognize the name
(without actually retrieving the profile) and perform some activity based on
known conventions for that profile. For instance, search engines could provide
an interface for searching through catalogs of HTML documents, where these
documents all use the same profile for representing catalog entries.
===

This seems to be saying that when a search engine encounters a
document, it can examine the @profile value, and in some cases will
simply 'know' what vocabulary is represented by the URI, without
having to retrieve anything. The vocabulary identified by the URI
could then be used to present a specific search form to users that
want to search on documents of this type; the search form would
contain selection criteria based on the values in the taxonomy that
the @profile URI identifies.

The second 'snipped' part looks like this, in full:

===
As a link. User agents may dereference the URI and perform some activity based
on the actual definitions within the profile (e.g., authorize the
usage of the profile
within the current HTML document). This specification does not define
formats for
profiles.
===

This is less specific, but I would suggest that the "some activity" is
intended to be something that makes use of the vocabulary specified by
the @profile URI--or "reference lexicon" as it is described in the
spec--as opposed to being simply _any_ activity based merely on the
presence of a URI that means nothing.



ON BENEVELONT HTML

It seems to me therefore that HTML allows great flexibility in the use
of a 'metadata profile', but it's pretty clear on what such a profile
is, and it is also clear that a URI in @profile should represent one.
You say:

> At this point I start to wonder what planet you are on (with all due
> respect), because the html doc is benevolent - "here's a profile,
> interpret it how you like, link or ID" - your agent may have
> conventions

(What kind of "due respect" is it that questions someone's sanity!)

Anyway...

It's true that the profile value can be either a "link or ID", as you
say. But as I've shown, what that "link or ID" represents is still a
vocabulary--a "named dictionary of meta info" or a "reference
lexicon". Using such a URI simply to 'identify' the presence of RDFa
would not involve such a taxonomy (unless as I said above we add some
values).

Regards,

Mark

[1] <http://www.w3.org/TR/html401/struct/global.html#h-7.4.4>
[2] <http://www.w3.org/TR/html401/struct/global.html#h-7.4.4.1>
[3] <http://www.w3.org/TR/html401/struct/links.html#h-12.3>
[4] <http://www.w3.org/TR/html401/types.html#type-links>
[5] <http://www.w3.org/TR/html401/index/attributes.html>
[6] <http://www.w3.org/TR/html401/struct/global.html#adef-profile>
[7] <http://www.w3.org/TR/html401/struct/global.html#profiles>


-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@formsPlayer.com | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.

Received on Thursday, 13 December 2007 13:29:31 UTC