[whatwg] Creative Commons Rights Expression Language

[ddailey]

Sorry for joining in naively to a conversation I've not been following, but 
reading Karl's remarks on the facilitation of metadata entry for users, some 
discussions in the vicinity of the recent SVGOpen that concerned usability, 
accessibility,  and metadata made me think the following (that I suppose is 
rather outside the realm of HTML):

Suppose the user or author (since in an app the distinction is blurred 
somewhat) is building something like a graph (in the discrete math sense), 
an image repository, or even a diagram (though the categories of content 
here are heterogeneous, making the argument a bit more tenuous) using a 
guiwebapp (like inkscape for diagrams or 
http://srufaculty.sru.edu/david.dailey/svg/graphs30.svg for graphs). Let's 
say there are n basic entities (like graphs or images) for which metadata is 
required. Let us furthermore assume the metadata description language is of 
order 0 1 2 3  or 4 * and that the minimum number of user operations 
required to complete the metadata description for a single entity is bounded 
above by k.

We then may plot a user performance function that estimates the probability, 
p,  that users will actually succeed in entering data (as a function perhaps 
of not only n and k, but of the user's investment in the process). Clearly 
as n and k grow and as the user's investment in the process declines, so 
does p. We are interested, through, interface, in maximizing p.

I have a hunch (in math it is called a conjecture, but in CHI it is more 
like a hunch) that not only how, but also when, this conversation between 
user and software takes place affects the probability. For example if an 
artist were using Inkscape to draw SVG, then mandating a conversation about 
metadata each time a curve or gradient is completed is likely to drive users 
to AutoCad for their diagrams, even if wine is served.

In certain cases, it makes most sense to build that conversation as an "exit 
interview". If we will have k phrases to enter (using a grammar of graph 
theoretic phrases) for each of n objects, then we may wish to build a very 
comfortable GUI to facilitate that for all the affected entities upon 
closing the app: Dear user, you have just completed a schematic drawing for 
the Intel i-Chore 42x processor, would you now like to a) save b) enter 
appropriate metadata c) save and enter data d) drink wine. The notion is 
that a GUI enabling such, could if it were viewed as a stage or mode of 
development a) rely on the visualization of the opus as thus far created b) 
be appropriately rich to the order of the metadata description language and 
c) make the data entry process unbundled from the creation process, hence 
allowing diversification of the assignments of tasks to workers (e.g. the 
familiar phrase of the assessment revolt of 2028: "let the bureacrats do the 
bureaucracy!"). That isn't to say that we should not also facilitate the 
entry of data at each stage of the drawing process, with a sub-interface of 
the master metadata editor, but given the complexity that some metadata 
editors may have to convey, the nature of the conversation between user and 
software may not be allowed to remain entirely casual (that is, wine may 
need to be upgraded to tequila).

/fwiw
David

(by the way, an Intellectual Property/provenance description language such 
as the library and visual rights communities work with might be an 
interesting overlay for the web, provided both free and corporate models 
(together with ample graph theory) are included)

* define the order of a metadata description language as 0 if it consists of 
simple non-delimited strings, 1 if it consists of delimited strings (with a 
single delimiter), 2 if the delimiters are parentheses (required to match), 
3 if the delimiters act like parentheses of multiple flavors as in XML,  and 
4 if the language is fully graph theoretic (parenthesized strings plus cross 
linkages -- footnotes).

----- Original Message ----- 
From: "Karl Dubost" <karl at w3.org>
To: "Henri Sivonen" <hsivonen at iki.fi>
Cc: "Ben Adida" <ben at adida.net>; "Paul Prescod" <paul at prescod.net>; "Ian 
Hickson" <ian at hixie.ch>; "WHAT-WG" <whatwg at whatwg.org>
Sent: Sunday, August 31, 2008 11:20 PM
Subject: Re: [whatwg] Creative Commons Rights Expression Language



Le 29 août 2008 à 23:04, Henri Sivonen a écrit :
> Also, having more metadata leads to UI clutter and data entry  fatigue 
> that alienates users. In the past, I worked on a content  repository 
> project that failed because (among other things) the  content upload UI 
> asked for an insane amount (a couple of screenfuls  back then; probably a 
> screenful today) of metadata when it didn't  occur to system specifiers to 
> invest in full text search. More  metadata isn't better. Instead, systems 
> should ask for the least  amount of metadata that can possibly work (when 
> the metadata must be  entered by humans as opposed to being captured by 
> machines like EXIF  data). See also
> http://www.w3.org/QA/2008/08/the-digital-stakhanovite

hehe. This was a-good-try-but-mischaracterization-from-the-ministry-of-
truth to associate this article with the rants on metadata :) Let's
clarify.

What I explain in the article is not the volume of metadata, but the
volume of items and the context of usage.

    1. Extract anything you can from the data itself (exif, iptc, xmp,
modifications, date)
    2. Give a possibility in the UI to modify or add data.

In a business environment, you might have to give metadata about a
work. I do it in my every day job. I give titles to my emails, I put
comments in my cvs commits, etc. etc. These are all constraints. Not
adding the data would still work technically.

For my own personal photo, I don't (want/have) time to put plenty of
metadata. And that's fine. I do though bulk metadata at a regular
pace, for location (ex: all these selected photos have been taken in
Taiwan with the help of GUI tools. Yes tools save my life).


Having a UI cluttered with fields to enter is not a failure of
metadata, it is a failure of the project in the social and business
constraints of the project.



-- 
Karl Dubost - W3C
http://www.w3.org/QA/
Be Strict To Be Cool