- From: <gordon@gordondunsire.com>
- Date: Thu, 29 Jul 2010 14:25:31 +0100 (BST)
- To: public-xg-lld <public-xg-lld@w3.org>
- Message-ID: <2122362123.259808.1280409931473.JavaMail.open-xchange@oxltgw15.schlund.de>
All My silence is general agreement, although there are perhaps different ways of categorising the FR users tasks/needs within the dimensions. But I don't think that would make much practical difference, and the current taxonomy is fit for purpose. Karen (post-this) is right to say that the FR models are somewhat siloed, although it should be pointed out that they have, over time, taken into account the museum (e.g. FRBRoo) and archive (e.g. FRAD) communities. I think there may be two main causes for any silos, which this group should bear in mind: 1. The classic Libraryland environment begins with the FRBR Manifestation, a finished product of the publishing industry (or manuscript). It is only recently that pre-manifestation metadata has become important - publisher metadata can be copied and recast to save cataloguer time, but this has only become generally feasible as a result of initiatives such as ONIX, the RDA/ONIX Framework, and, indeed, the linked-data movement. The FR family is also focussed on user tasks which consume metadata; the generation and maintenance of metadata by users, professionals, or machines has been out-of-scope (the FRAD stuff about agencies, rules, and controlled access points might spill over, but the focus is on how these affect the metadata content). 2. Libraries operate in the real-world. They have customers (lots of them) with expectations (changing, of course, but mostly legacy); they are funded by real organisations and real money (never enough). The funders have their own expectations. As a result, libraries tend to be conservative. They also tend to be cautious, having been burned on numerous occasions in the past by "new technology" (but they know that such technology is their saviour). It's messy, illogical, and, in the UK at least, gets consistently high approval ratings by customers (the public taxpayers). Needless to say, these factors vary from country to country and culture to culture - so IFLA and other national/international library collaboration on standards and models is, relatively-speaking, outstanding and as good-as-it-gets. Something missing from the Dimensions is any hint of institutional repositories (and therefore Dublin Core); these are within scope, as, in the UK at least, their metadata is often maintained or quality-controlled by libraries. Cheers Gordon On 29 July 2010 at 10:08 Antoine Isaac <aisaac@few.vu.nl> wrote: > Hi Marcia, > > Trying to revive that before this afternoon's discussion... > > I agree with the importance of exploring, but can't it be just merged with > "browse"? > > Btw there were still some elements remaining from our discussion at [1] which > I have tried to fit in the dimensions [2], assuming that Gordon's silence was > agreement ;-) > > Cheers, > > Antoine > > [1] http://lists.w3.org/Archives/Public/public-xg-lld/2010Jul/0022.html > [2] http://www.w3.org/2005/Incubator/lld/wiki/Dimensions > > > > Thanks for all the great work on getting the USE CASE template there. > > > > At the *Dimensions *page, currently the template has: > > > > * Users needs > > o Identify > > o Browse > > o Access > > o Retrieve > > o Integrate > > > > Suggest to add: > > . Explore > > > > The current listed users needs seemed to be good for the bibliographic > > data. If it is for subject authority data, there should be an ‘Explore’ > > added. It is a task included in FRSAD (Functional Requirements for > > Subject Authority Data, which is released [1] and will be published by > > IFLA). Gordon already mentioned this in his email (see his 7/8/10 > > email). He has the best overview of all three FRBR family models’ > > harmonization, which also includes the user tasks identified by three > > models. > > > > Users use subject authority data (e.g. any thesaurus, subject headings > > list, taxonomy, classification...) to explore relationships between > > subjects and/or their appellations (e.g., to explore relationships in > > order to understand the structure of a subject domain and its > > terminology). This task is seen not only among information professionals > > but also end-users. The task was introduced by FRSAR Working Group based > > on a subject authority data use survey which received nearly 800 > > responses worldwide. [2] > > > > Marcia > > > > [1] http://www.ifla.org/node/1297 > > [2] /Ibid/., p. 33 and p.36. > > > > On 7/12/10 5:21 PM, "Antoine Isaac" <aisaac@few.vu.nl> wrote: > > > > Hi Emmanuelle, > > > > > > > I've started the work on merging the templates as intended in our > > last call. > > > I didn't create a new page, but rather improve the existing one, as > > > the changes were very limited (introduction + dimensions). Also we > >can > > > always roll back to an older version. > > > > > > So the following 3 pages have changed : > > > [1] merged the introductions and changed the "Linked data > > dimensions" paragraph > > > [2] added references to the rationale page > > > [3] simplified the dimensions page. > > > > > > There is still work to be done on the dimensions' content. > > > > > > Feedback welcome > > > > > > Cheers > > > Emmanuelle > > > > > > Thanks a lot for this! Now that I read the text you've moved to the > > intro of the template [1], it really looks like we-could re-use it > > almost as such for the wider call for use case we envision :-) > > > > Re. feedback on the content of the template, my most important > > comment concerns the use of the "dimensions" at [3] in the sections > > of the use case template [1]. > > My first understanding of the "library linked data dimension" > > section, based on the "dimensions" of the Prov XG [4] initially > > there [5], is that this section would be rather technical, > > implementation-driven. In fact, to me the examples for filling the > > "library linked data dimension" section should come from the > > "topics" that we assembled over the past weeks (now at [6]). [4] is > > really closer from [6] than it is from [3]. > > > > I tried to point in the last call that our use case dimensions at > > [3] would be most useful for "stimulating" (re-using Stu's perfectly > > fitting word) the filling of the "use case" section. And I still > > believe it should be the case, looking at the instruction you left > > for that section: > > [The use case scenario itself, described as a story in which actors > > interact with systems, each other etc. It should show who is using > > linked data technology and for what purpose. Please mark the key > > steps which show requirements on linked data in italics. > > ] > > I think all the categories at [3] can fall in this description. > > Maybe only "systems" may fall as well in the "background and current > > practice" section. > > > > > > Now, I think the point on which we fundamentally agree (and which > > may explain the above disagreement ;-) ) is that *the "use case > > dimensions" at [3] should stimulate something that comes before what > > the "linked data topics" at [6] would stimulate*. > > The more I look at it, the more I wonder why the Prov XG had put > > their "provenance dimensions" before their "goal" and "use case > > scenario". I can see a logic here, but it's one of someone with a > > quite clear view on the domain's technical points--the Prov XG > > provided the UCs themselves--not necessarily the one of a true > > application owner (i.e., "business"-oriented). > > > > > > I would thus suggest to have the following order: > > 1. Name; 2. Owner; 3. Background and Current Practice; 4. Goal; 5. > > Use Case Scenario [suggesting the use case dimensions at [3]); 6. > > Problems and Limitations; 7. Library Linked Data Dimensions > > (pointing to the topics at [6]; 8 Unanticipated Uses (optional); 9 > > Existing Work (optional) > > > > This could have the benefit of illustrating the natural > > complementarity between "problems and limitations" and "LLD > > dimensions". For many of the Prov XG's use cases, I feel that it is > > the informal gathering of problems that leads to the more formal > > identifications of the dimensions. > > > > Would people around here agree? > > > > > > On a much smaller scale, I was not so-happy with making the > > distinction between "devices" and "communication" in the use cases > > dimensions at [3]. There is a distinction indeed, but I'm not sure > > we want to get that granularity here. > > > > But as said it is indeed much less important, and I realize I've > > already written one page on the order of the sections of the > > template alone so I'll stop here :-) > > > > Cheers, > > > > Antoine > > > > [1] http://www.w3.org/2005/Incubator/lld/wiki/UCTemplate1 > > [2] http://www.w3.org/2005/Incubator/lld/wiki/UCRationale > > [3] http://www.w3.org/2005/Incubator/lld/wiki/Dimensions > > [4] http://www.w3.org/2005/Incubator/prov/wiki/Provenance_Dimensions > > [5] > > > > > >http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=UCTemplate1&oldid=86#Linked_Data_Dimensions > > > > <http://www.w3.org/2005/Incubator/lld/wiki/index.php?title=UCTemplate1&oldid=86#Linked_Data_Dimensions > >> > > [6] http://www.w3.org/2005/Incubator/lld/wiki/Topics3 > > > > > > > Hi all, > > > > > > I've started the work on merging the templates as intended in our > > last call. > > > I didn't create a new page, but rather improve the existing one, as > > > the changes were very limited (introduction + dimensions). Also we > >can > > > always roll back to an older version. > > > > > > So the following 3 pages have changed : > > > [1] merged the introductions and changed the "Linked data > > dimensions" paragraph > > > [2] added references to the rationale page > > > [3] simplified the dimensions page. > > > > > > There is still work to be done on the dimensions' content. > > > > > > Feedback welcome > > > > > > Cheers > > > Emmanuelle > > > > > > [1] http://www.w3.org/2005/Incubator/lld/wiki/UCTemplate1 > > > [2] http://www.w3.org/2005/Incubator/lld/wiki/UCRationale > > > [3] http://www.w3.org/2005/Incubator/lld/wiki/Dimensions > > > > > > > > > > > > > >
Received on Thursday, 29 July 2010 13:26:11 UTC