From craig.e.shea at gmail.com Sun Aug 1 12:43:48 2010 From: craig.e.shea at gmail.com (Craig Shea) Date: Sun Aug 1 12:43:51 2010 Subject: [uf-new] RFC: Proposal for a (book) title microformat In-Reply-To: <20100721120457.0dd2274b@miranda.g5n.co.uk> References: <20100721120457.0dd2274b@miranda.g5n.co.uk> Message-ID: Toby, All: I looked up information on the FRBR and see that you are right about the similar distinction that I am making. In addition, I did research on the citation microformat and have concluded that, though there may be overlap there, they really serve different purposes and is not a suitable format for how I envision using the "title" microformat. If anything, it appears that I should read up on FRBR more and model a title microformat on the FRBR. Secondly, it would also seem that the proposed citation microformat could also benefit from being modeled after the FRBR. If this were to happen, then perhaps my proposed microformat and the citation microformat would indeed be one and the same, serving the same purpose. The most interesting thing about the FRBR study is that it not only encompasses written works, but all types of artistic works. This could have even more implications for microformats such as hAudio, hAtom, and hMedia. Afterall, if microformats is about "paving the cow paths", I'd say that FRBR, though not well-known, provides a wide "cow path" which could easily be transformed into a high-speed information interstate highway! Secondly, it appears there has been no work on the citation microformat (the pages don't seem to have changed much in the last 2 months). Is this citation currently being actively developed? Is there interest in developing that microformat further, especially in regards to researching the implications of the FRBR study and how its recommendations might be used to represent this information for consumption, distribution, and aggregation? I must admit, that I would love to be able to use a microformat for my final project that would allow intelligent user agents (such as Firefox augmented with Operator+) to "discover" this information and allow easy access to it. This could have such profound impacts on sites such as Amazon.com, OReilly.com (which currently uses RDFa), and other well-known sites that sell or provide information on artistic works. ~ Craig E. Shea On Wed, Jul 21, 2010 at 7:04 AM, Toby Inkster wrote: > On Tue, 20 Jul 2010 20:34:08 -0400 > Craig Shea wrote: > >> Before going further, I must define the term "title" vs. "book(s)". A >> title is something that an author writes. A book is a published >> representation of a title. > > This distinction is similar to the distinction that the Functional > Requirements for Bibliographic Records (FRBR) makes. FRBR was developed > by librarians about 15 years ago as the gold standard data model for > books and similar. It's often used as a design guide when programming > software for cataloguing books. > > Rather than two levels like your suggestion above, FRBR distinguishes > between four levels: > > ? ? ? ?Work > ? ? ? ?Expression > ? ? ? ?Manifestation > ? ? ? ?Item > > A "Work" for example might be the Hitchhikers' Guide to the Galaxy. > This might have several Expressions: for example an English language > version, and a French language version. The English language version > might have several Manifestations - e.g. the softback version measuring > X by Y millimetres, published in 2006. All copies of that Manifestation > have the same physical and intellectual characteristics. Lastly, a > Manifestation will typically have many thousands of Items, as an Item > refers to a single copy of a book. > > Modelling books at each of these levels has its uses; and understanding > the relationship between them is useful too. > > For example, a library probably wants to keep track of Items, and also > group them into Expressions so that it knows that if one Item of a book > has been checked out, the next borrower might be interested in another > Item of the same Expression. > > A microformat for books probably doesn't need to model all of the FRBR > levels, but it should probably aim to align its model with at least one > FRBR level. So, for example, if hTitle was aiming to line up with an > FRBR Expression, we'd know that a review could mention the quality of > the translation; whereas if it was aiming to line up with an FRBR Item, > the review might mention whether its pages were torn. > > Here's a quick FRBR primer: > http://www.loc.gov/cds/downloads/FRBR.PDF > >> It looks like there is some overlap in terms of class names and >> what-not, I'll give you that. ?the thing that concerns me is the fact >> that that format is called "citation". > > If there was a decent book microformat, a citation microformat could > emerge quite easily as a by-product: > > When the book title is marked up as: > > ? ... > > it's a citation; otherwise, if it's > > ? ... > > then it's a non-citation mention of the book. > > -- > Toby A Inkster > > > > From JOttevanger at IWM.ORG.UK Sun Aug 1 12:48:00 2010 From: JOttevanger at IWM.ORG.UK (Jeremy Ottevanger) Date: Sun Aug 1 12:48:31 2010 Subject: [uf-new] RFC: Proposal for a (book) title microformat (Out of office auto-response) Message-ID: Thank you for your e-mail. I am on leave until August 16th and will reply when I return. Regards, Jeremy Ottevanger From sky at columbia.edu Wed Aug 18 07:19:11 2010 From: sky at columbia.edu (Schuyler Duveen) Date: Wed Aug 18 07:19:17 2010 Subject: [uf-new] RFC: @rel for privacy policy and T&C links Message-ID: <4C6BEBDF.1090206@columbia.edu> My use-case is that I'm automating the embedding of media from other sites into a third-party site [1]. Some sites have requested that we include their Terms and Conditions (T&C) and Privacy Policy links next to the content, thus I'd like a way to automatically discover this. I propose a single new @rel value, 'privacy' thus: Privacy Policy Terms and Conditions IANAL, so I'm not entirely clear if there are subtle differences between a license and T&C, but here I assume T&C are always licenses. These links are ubiquitous throughout the web, and I believe there are even some legal domains which require sites to have such links. [2] There is a related @rel for machine-readable privacy policies: http://www.w3.org/TR/P3P/ which proposes embedding such a file in many ways, one of which would be: but this is outside of my use-case, since it's a machine-readable form. Thoughts? cheers, sky [1] If you want to know more, see: http://ccnmtl.columbia.edu/mediathread more or less the oEmbed use case, but even when a oEmbed url is not available) http://www.oembed.com/ [2] http://en.wikipedia.org/wiki/Privacy_Policy#Applicable_US_law From mail at tobyinkster.co.uk Wed Aug 18 15:33:25 2010 From: mail at tobyinkster.co.uk (Toby Inkster) Date: Wed Aug 18 15:33:46 2010 Subject: [uf-new] RFC: @rel for privacy policy and T&C links In-Reply-To: <4C6BEBDF.1090206@columbia.edu> References: <4C6BEBDF.1090206@columbia.edu> Message-ID: <20100818233325.51f143a3@miranda.g5n.co.uk> On Wed, 18 Aug 2010 10:19:11 -0400 Schuyler Duveen wrote: > which proposes embedding such a file in many ways, one of which would > be: href="http://catalog.example.com/P3P/PolicyReferences.xml"> > > but this is outside of my use-case, since it's a machine-readable > form. rel="P3Pv1" is rather irksome: generally speaking, a rel value shouldn't make any assumptions about the media-type of the document being linked to. As it happens, I suggested deprecating rel="P3Pv1" in favour of rel="privacy" way back in 2003 when reviewing XHTML 2.0: Note that I don't necessarily agree with everything in that message any more (a lot can change in 7.25 years!) but still think that a more general link type would be an improvement. A solution you could try is to include a rel="P3Pv1" link to a URL that performs content-negotiation between a P3P file and something human-readable. -- Toby A Inkster From xn--mlform-iua at xn--mlform-iua.no Sat Aug 21 19:12:25 2010 From: xn--mlform-iua at xn--mlform-iua.no (Leif Halvard Silli) Date: Sat Aug 21 19:12:32 2010 Subject: [uf-new] include pattern: has a11y issues, suggest instead Message-ID: <20100822041225132970.53733078@xn--mlform-iua.no> Proposal: introduce AREA@href as an alternative to OBJECT@data in the include pattern. [1] OBJECT@data#fragment isn't perefect - the wiki tells that it: (1) causes extra http requests in many browsers, (2) needs to be actively hidden from GUI browsers (e.g. by setting the dimensions to zero) (3) tells authors to use a@href, whenever extra http requests is a problem. The wiki fails to mention: (4) accessibility risk: unless its dimensions are set to zero and/or CSS display:none is used, then Webkit browsers render the current page as the content of the OBJECT. A screenreader will then read the content of the page as the content of the OBJECT@data element. (5) display issue in IE: "foo bar" is displayed as 'foobar' instead of 'foo bar'. Working around this is complicated. Hiding the OBJECT has not effect on the problem. (6) the command line browser Links notify the user, visually, that the code contains an OBJECT. (7) Several of the issues above may cause authors to use A@href instead of OBJECT@data AREA@href - in comparison: History: area@href was been discussed, inconclusively it seemed, in 2006. [2] (And may be later also?) Example: VoiceOver test: works: outside MAP element, the link isn't read. No CSS needed. JAWS test: works if area.include{visibility:hidden} NVDA test: works if area.include{visibility:hidden} Other screenreaders: ? GUI browsers: automatically invisible, without CSS HTTP requests: not an issue HTML validity: Neither HTML4, XHTML1 nor the HTML5 draft consider an AREA element outside a MAP element as valid. Reuse in RDFa/Microdata: easy to use area@href in RDFa/Microdata Evaluation: AREA@href: that CSS is needed to hide it from screenreaders is a drawback - OBJECT can be hidden, for all UAs, via width="0" + height="0". (Whether the @alt is empty or not, does not have any effect on JAWS and VoiceOVer.) However, if - in reality - authors choose a@href due to the problems with object@data, then screenreader users will anyhow be told that the AREA@href is a link. (It isn't a link, though, unless it is located inside a MAP. This is only an issue if visibility:hidden is *not* used, however.) AREA@href seems easier and safer to use than OBJECT@data. However, the validity issue needs to be solved (could be solved in HTML5). And the requirements w.r.t. screenreaders must be finalized: it seems logical to *require* that authors use area.include{visibility:hidden}. A fine detail is the use of @alt: whenever visibility:hidden fails to be used, then a meaningful @alt text may work better than the empty string, since the empty string seems to lead the screenreader to read the link address in place of the @alt text. Thus from one point it makes sense to permit a non-empty @alt - though I don't really propose that. Now, over to you - does this sound like an idea? [1] http://microformats.org/wiki/include-pattern [2] http://microformats.org/discuss/mail/microformats-discuss/2006-June/004357.html -- leif halvard silli