- From: Dan Brickley <danbri@danbri.org>
- Date: Fri, 13 Aug 2010 16:28:56 +0200
- To: Jonathan Rees <jar@creativecommons.org>
- Cc: AWWSW TF <public-awwsw@w3.org>, foaf-dev Friend of a <foaf-dev@lists.foaf-project.org>
(excuse the x-post folks) On Fri, Aug 13, 2010 at 4:04 PM, Jonathan Rees <jar@creativecommons.org> wrote: > I was going to say that 200 responses to GETs of URIs that name members of > foaf:Document were OK... guess not. Need to look for other examples. > So the issue (which I'll respond to properly on foaf-dev when I get back from vacation) is essentially FRBR-related. FOAF currently has a single very broad class 'Document' which encompasses all kinds of docs, including the notion of 'that particular book in your hand with the front page signed by the author'; but also a Web page. This simplicity has served us pretty well, but can lead to confusion eg. in the case of FOAF's sha1 property, which makes sense only when applied to a specific bag of bits. Consider two different documents, both with IDENTICAL content 'eg. the string "Nothing to see here.". They could be written independently by different primary authors on different days using different software, and yet have exactly the same sha1 checksum. Until we get around to figuring out how to handle these radically different notions of document which have to peacefully co-exist as foaf:Document right now, we need a kind of modesty when we go around saying what kinds of thing a Document can NEVER be. And since foaf:Document covers real world artifacts, like a single physical book, as well as sets of books (various FRBR views of literature), ... it is hard to sustain the view that physical documents can't ever be directly identified with the physical artifacts that embody them. If the spatial thing on my bookshelf can be a foaf:Document, so can a parchment in a museum, a poster on a wall, a series of mime-typed zeros-and-ones, the hardback edition of TimBL's Weaving the Web, a signed copy of the same, a painting made on a wall in ink, or on a body in paint... All the time we only help ourselves to a single broad class for all this diversity, we can't be too absolute in making disjointness claims. Much the same goes for Agent. Both FOAF and Dublin Core more or less say an agent is something that does stuff (DC has slightly fancier wording but equivalent sense). It turns out to be hard to define classes of thing that can't be said to have 'done something' under any circumstances; eg. the hailstone that broke the window, the storm that flooded the field. Documents are similarly subtle, and the odd thing for OO / DL style modelling is that these classes can still be incredibly useful, even if they fall apart upon closer inspection. Re FRBR-ish distinctions, my instinct is to avoid treating FRBR concepts directly as classes, and instead to allow user-defined sets to be more liberally used, but that's quite another story. Some rough sketch of that here, ... http://www.flickr.com/photos/danbri/2891150205/ and again more another time! cheers, Dan
Received on Friday, 13 August 2010 14:29:29 UTC