W3C Content Labels

Table of Contents

• 1 Introduction
• 2 Detailed requirements and definitions
• 2.1 A cLabel and its metadata
• 3 System architecture
• 4 Encodings
• 4.1 The RDF Model
• 4.2 A Non-RDF model

1 Introduction (Informative)

As set out in the charter, the group looked for "... a way of making any number of assertions about a resource or group of resources." Furthermore "... those assertions should be testable in some way through automated means."

fwiw, I think we should revisit what "testable" means - i.e. an assertion that I wrote a document is not "testable" as such but is an assertion that we need to be able to make within the scope of what we are trying to do.

also fwiw, I think that we need to be clear what we mean by automatic testing. We definitely mean that the assertions need to be expressed in a form that an automated tester - or any automated process - can parse effectively. We do not mean, imo, that assertions that are not open to automatic verification are not valid assertions. As Paul often points out, the WAI stuff is partly testable.

Further, imo, I think we need to introduce the concept of verification, verifiable, authentic and so on.

summary: I think we need to include a section on refinement and clarification of charter following the study the group has put in

In addition to its original sponsors, the XG attracted participation from AT&T, AOL Inc., the Center for Democracy and Technology, Centre Virtuel de la Connaissance sur l'Europe, the Internet Association of Japan, Maryland Information and Network Dynamics Lab at the University of Maryland, Opera Software and RuleSpace. The diverse membership reflects a widely recognized need to be able to "label content" for various purposes. These range from child protection through to scientific accuracy, from the identification of mobile-friendly and/or accessible content to linking of thematically-related resources.

Initial work focused on revising and improving the use cases given in the charter, and the derivation of high level requirements from them [use]. Based on that work, the group was able to create a more detailed set of requirements and definitions that are more readily expressed in technological terms.

Editor's note: Add more when possible about the tech used here, where RDF is appropriate, where it is not etc.

Process by which the conclusions were reached.

Is there need for discussion the above plus SysArch etc. and the other stuff that actually gets done, as well as work that is yet to be done. Need for reference to use cases?

2 Detailed requirements and definitions (Informative)

Definitions

assertion - the expression of an opinion at a point in time using a defined vocabulary about a resource or set of resources and optionally their directly or indirectly linked resources.

resource - the result of dereferencing a URI

vocabulary - a set of named properties are applicable to an aspect of [experiencing] a resource or to the resource itself, together with the data type of the values that those properties may assume and optionally a constrained list of such values. i.e. it defines the possible values the meaning and relationship of x and y in the statement "The value of property x in respect of Resource R is y"

Note to self mainly, if x has primarily boolean values true/false should it also be possible to code for "unknown", "indeterminate", "partly true".

Certificate -

Trustmark -

Validation

Claim- an assertion that is subject to validation

and so on ...

Fundamentals

1. It must be possible for both content provider [resource creator] and third parties to make assertions about resources.
2. The assertions must be able to be expressed in terms chosen from different vocabularies. Such vocabularies might include, but are not limited to, those that describe a resource's suitability for children, its conformance with accessibility guidelines and/or Mobile Web Best Practice, its scientific accuracy and the editorial policy applied to its creation.
3. It must be possible to group assertions from an arbitrary number of vocabularies. A group of assertions of this kind is called a content label, written cLabel. Editor's note: cLabel or CL?
4. It must be possible to group resources and have cLabels refer to that group of resources. That is, cLabels can refer to all the pages of a Web site, defined sections of a Web site, or all resources on multiple Web sites. Editor's note - is this broad enough?
5. It must be possible for both content authors and third parties to make cLabels for any given resource

Label semantics

1. A cLabel is the expression of claims made only by the party that created it.It is the expression of an opinion of a person or organization or an automaton, from a point of view (limited by the vocabulary or vocabularies chosen), potentially qualified by the limitations of present knowledge, expressed at a point in time about the current state of ...)
2. Vocabularies must support the grouping of assertions so that a single assertion can take the place of a number of other assertions. (i.e. e.g. the vocabularies must support the idea of making granular assertions as well as composite assertions. Examples include WAI AAA, mobileOK and age-based classifications.)
3. Labels must also support the addition or subtraction from composite assertions - the first of these would appear to be supported by the ability to group a composite assertion with atomic ones. The second would appear to require in addition, negative assertions. Further, those negative assertions would, for the sake of a client being able to understand the meaning of a composite assertion which is subtracted from, without having to parse the relevant vocabulary, hence negative assertion probably need to be nested in a composite assertion. Example AAA minus x and y. Vocabulary maybe should be able to constrain whether negative assertions can be made??? Also this suggests requirements as to the usability or utility of labels absent the ability to retrieve and/or parse the accompanying vocabs.
4. More than one cLabel can refer to the same resource or group of resources. Since conflicting labels are therefore permissible, their acceptance lies with the end user
5. It must be possible for a resource to refer to one or more cLabels. It follows that there must be a linking mechanism between content and labels.
6. cLabels must be able independently to point to any content
7. It must be possible to make assertions about cLabels using appropriate vocabularies. That is e.g., a cLabel can have metadata describing who created it, what its period of validity is, how to provide feedback about it, a who last verified it and when.
8. It must be possible for a cLabel to be associated with its metadata and vice versa.

Fitting in with commercial or other large scale workflows

1. It must be possible for cLabels and cLabel metadata to be authenticated. That is, it must be possible to verify that a cLabel is an authentic expression of its creator's claims (i.e that the person who said they created it really did express the opinions represented)
2. It must be possible to validity opinions about a label and / or its metadata - that is that it must be possible to either affirm or deny assertions that are made in the label or its metadata.
3. It must be possible (independently) to link to and from validity opinions and what they are expressing opinions about. [this is actually true of all types of opinion, I think]
4. It must be possible to create and edit cLabels without modifying the resources they describe.But this need not be the only or even primary means of adding labels to content.
5. cLabels I think it is actually the vocabularies that must support defaults must support defaults.
6. cLabels must be able to override defaults.
7. It must be possible for a labeling organization to make all its labels data available and to define the means through which it can be accessed. This may be through a Web Service, as an xml file or another means.does this mean that it must be possible to group cLabels? or does it just mean that cLabels, however they are stored, must be accessible. If so I wonder why exactly we are saying it? See also the non-requirement that labels from different labellers do not need be be grouped [below]

Encoding labels for humans and machines

1. It must be possible to express cLabels and cLabel metadata in a machine readable way.
2. The machine readable form of a cLabel and cLabel metadata must be defined by a formal grammar
3. cLabels must provide support for a human readable summary of the claims it contains
4. u. It must be possible to express cLabels and cLabel metadata in a compact form

   vocabularies also need encoding. So do validation statements.

   vocabularies need identifiers and resolution mechanisms.

   Non requirements

   It is not necessary for a cLabel to consist of assertions that are made by different entities. [i.e. a cLabel is the expression of opinion of only one party per f. above and there is no foreseen requirement to group labels from more than one party]

cLabel {
  That resource R has the property P1 is true
  That resource R has Property P2 that has value V
  That resource R meets WCAG 1.0 AA is true
  That resource R was created in accordance with satisfactory procedures is 
true
}

A URI may stand in for a group of resources, as follows:

1. it may refer to all resources that match the pattern defined by the URI [which is actually an expression with wild-cards?] with the proviso that those resources must be reachable by following iteratively links originating in the original URI - e.g. http://www.w3c.org/ means all URIs that are linked from the home page that match http://www.w3c.org/*
2. a list of URIs where no such linking is implied
3. there may be exclusions from the list
4. the target URI may include transcluded content and the label may refer to the transcluded content (in which case the exclusions are also needed e.g. this page is fine for kids with the exception that the little photo at the bottom may be upsetting to some)
5. the target URI may include links and the label may refer to the targets of such links (this is a general case of 1 above)

metadata {
cLabel was created by $organization
    {
      has the e-mail address mail@organization.org
      has a homepage at $url
      has a feedback page at $URL
       ...
    }
cLabel was created on $date
cLabel was last reviewed by $person
}

validity {
metadata and cLabel verified by $organization  
  { has email sss ... }
verified on $date}

Acknowledgements

The editors acknowledge significant written contributions from:

• etc.