See also: IRC log
<antoine> minutes are actually good!
TomB: Propose that we accept last week's minutes. Apologies for technical difficulties.
Resolved: To accept the minutes of previous teleconference
<ww> Slides on CKAN for LLD: http://eris.okfn.org/ww/2010/11/ckanlld
William: CKAN as free software is being used by governments, community groups and (most interestingly) LOD group to make the LOD cloud diagram. It's collaboratively developed as a wiki. Various metadata types. Groups are curated, anyone can create a group, and say which packages should be in a group, according to criteria.
William: CKAN has RDF export of packages. Extras fields need to be mapped on a case-by-case basis.
<TomB> +1 for lld group on CKAN
<TomB> +1 for wiki page
William: I suggest creating CKAN LLD group and a wiki page on the XG wiki to establish our conventions.
Antoine: Bibliographic group (http://ckan.net/group/bibliographic) would be an alternative starting point.
<marcia> +1 ww
<jodi> more on CKAN and LOD: http://blog.okfn.org/2010/09/03/next-version-of-the-linked-open-data-cloud-based-on-ckan/
Antoine: Karen, Jonathan, Ed, Ross and others are admins for the CKAN Bibliographic group.
<Asaf> but here's an example from that group: -> http://ckan.net/package/hungarian-national-library-catalog
Ed: Two questions: 1) Bibliographic group on CKAN now is not specifically about LD - just bibliographic data in general. That group might contain packages referring to open MARC data. 2) Would Richard Cyganiak be ok with our using the LOD group as a starting point? It already contains many bibliographic Linked Data sources.
ww: We would need to negotiate with Richard to see whether we're looking for the same criteria etc.
William: The existing CKAN Bibliographic group is fairly open; Linked Data is not required.
<AnetteS> can a dataset be in more than one ckan group?
William: We can ask the admins, who are on the call.
Ed: What is the scope? What kind of datasets would we list?
<edsu> here's richard's lodcloud group on ckan: http://www.ckan.net/group/lodcloud
Marcia: The name 'Bibliographic' data might limit the focus. What about thesauri, and so on?
<GordonD> Non-bibliographic linked data of interest: circulation data, library location and directory data ...
<jodi:> edsu: can you quickly pull up the colored cloud, where the blue (or something) is the library/bib-related? to give a sense of the scope
<jodi> edsu: thanks, the light green is the part I wanted to point out there. :)
<Zakim> TomB, you wanted to ask whether a dataset is "in" one group or another, or merely referenced?
Antoine: We're not interested only in bibliographic data. We could have an included dataset, i.e. we create a set which is automatically added to the LOD cloud group. Want to include the bibliographic data group. What are the tech limitations of CKAN? Can we include everything into the LOD cloud?
<edsu> antoine: you can probably use tags to sub divide datasets in a group
Tom: These are overlapping groups. We're not entirely contained in either CKAN group: LOD or Bibliographic. Can we reference existing datasets in CKAN? If so, let's create our own list and reference anything already described in the LOD and Bibliographic CKAN groups. Then we wouldn't have to worry so much about...
William: Could be in any number of packages. No inclusion/subsetting relations, but we can look into how to do that.
Antoine: Different colors in LOD, Richard wanted help subclassing.
<scribe> ACTION: William: to summarize options for using CKAN to the list, before next concall [recorded in http://www.w3.org/2010/11/11-lld-minutes.html#action01]
<GordonD> We could invert the approach - what in LOD is of interest to LLDXG?
<antoine> GordonD+ - that's what I'd like to have: "tagging" some LOD sets with something like a "LLD" tag
TomB: Jeff and Alexander - assess progress on analyzing the clusters. How far have we gotten? We've made lots of attempts to visualize connections between things. Must hack through the thickets and move towards segments of a draft report. The 7 months we have left are going to zip by in a flash. We need to have chunks of text to review for a draft.
Jeff: Alexander and I have
started a dialogue through email about the problems. Must
convince each other that the patterns exist. There are 6-7 of
them (LCSH is the disputed one.) 5 are descriptions of
datasets--authority data we want to express in Linked Data.
The other one, enrichment, is more of a meta case.
Enrichment is nice: to explore what these use cases have in common. SKOS is a nice level of abstraction -- naming. Not clear why there's tension about naming. Some things are attached to the name, some are attached to the thing. I can imagine using SKOS but it's not the only way to do that. Would like to explore that with VIAF with the contributors, to get comfortable with it, explore alternatives.
The FRBR point of view is different. Side-by-side comparison of the two perspectives -- each with their strengths and weaknesses. Certain classes of things appear to be in alignment, but I'm reluctant to merge them. As we go on, the differences will become apparent. I think the comparison/contrast will help.
Alexander: We already discussed
merging. Beyond the library point of view: we are interested in
real world things (and highly structured info) about persons
and corporate bodies. ... distinguish between two people with the same name.
Biographical information in the background.
... Perspective *between* libraries. Need to align, enrich
Linked Data. Local datasets, or link to existing external
1) Reuse of data between libraries
2) How non-library world can reuse our library data
... Need SKOS: these are the ontologies used outside of libraries. We have to follow both tracks (reuse within and outside libraries).
<marcia> +1 Jeff for seperating the thing from the labels of the thing. This model applies to names of people and corporate boday, as well as to others, such as concepts, works.
Alexander: To exchange our data with the outside world, we need the infrastructure to exchange WITHIN libraries. Otherwise it's really difficult to establish the second (outside libraries) track.
TomB: Reuse of data between libraries? Do we assume that this will be LOD?
Tom: What kind of difficulties are you talking about in reusing--agreeing on descriptive properties to use, or -- the technical details?
Alexander: both the properties
and the infrastructure
... Right now, MARC is how we exchange data. RDA can only succeed with the LD data structure. RDA as a cataloging structure is all about the linking of data.
... For RDA to work, a good infrastructure is needed.
Jeff: The idea of exchanging data
is worth discussing. In the MARC paradigm we're exchanging
... In the LD world, it's not clear. Caching is different from exchange.
<TomB> +1 with Jeff re: "exchanging" metadata - that's exactly what I was trying to get at
Alexander: Not the physical exchange, the reuse of existing data in my system.
<GordonD> I suspect the VIAF use case is the key uc in the authority data cluster. It covers interoperability of data between libraries and external communities; but needs to be extended to LLD of individual authority files.
Alexander: If I have a cataloging system or the front-end (e.g. OPAC), the user can search on a number of Linked Data sets.
<marcia> I can understand Alex
Alexander: With LD, can search on a worldwide set of data. So it's reuse, not exchange.
<GordonD> That is, we should perhaps look at the application of FRAD/FRSAD at the local level, and its interaction with VIAF namespace at the aggregated level.
Jeff: How this gets represented
as a product of our (Alex+my) understanding. There's some
danger of our imagining what use case authors are doing, without enough
If there are no principles--or insufficiently strong principles--it's a mess.
Use FOAF, RDA, FRBR... we should encourage that but it's more fundamental. They should be interoperable, outside of the modeling choices.
Things need to be interoperable. It's not just about choosing patterns that we agree are the 'right patterns'.
<GordonD> +1 Jeff's suggestion that there is something more fundamental to be uncovered.
<marcia> +1 Jeff +GordonD
<Zakim> TomB, you wanted to ask if we are talking about a need for patterns to follow?
Antoine: I wondered at first --Do you think it's that the use cases are insufficiently documented? -- in which case you could ask the use case owners. But it sounds like it's more about the patterns.
Jeff: I suspect that they haven't thought about the details of which vocabs, patterns they'd use. I'm not sure that brings us more info.
Tom: I think we're talking about
patterns. I'd like to circle around to what the product
What will this cluster produce? It seems you have a really rich vein of issues and you're teasing them out well. I can imagine a 2-3 page section discussing the different design choices/patterns, citing the different use cases.
Correct me if I'm wrong, but I can imagine that you're pretty far along towards writing up something like that.
Other products... Clusters are normalizing use cases. You're talking about interacting with the use case authors. Do you see tweaking the use case descriptions and interacting with the use case authors as part of the outcome?
Jeff: What if we annotated the use cases to focus on certain points?
Jeff: 2-3 pages of design points and patterns, and then annotate to point out alternative patterns...
<marcia> +1 Jeff
Tom: Yes. And 2-3 pages is not a
magic number. But 10 is too many: We don't want to write a book
in the next 7 months. Writing it down will help.
... Want the design choices and patterns listed, so that the alternatives are clear.
... Want to look beyond that: Where is the work? Which problems have the highest priority? Where do we recommend that people pay attention and focus resources moving forward in order to resolve the issues?
Antoine: I support that.
Tom: If you can rough out an analysis, even as an outline, and push it to the list, that would be great.
TomB: Too many overlapping categories on the wikis. Clusters, Topics, Goals, Requirements, Vocabularies, Developments/Curation/Use, Summary. (May want to publish summaries with annotation in an appendix.)
Tom: How can we most efficiently
visualize and make the connections between clusters, topics,
goals, requirements? So that people can refer to these easily
as writing? A report is the ultimate goal.
... We had Paul Walk's clustering using a database and tools, we have a table that tries to cross-reference use cases. We have various tools. Jodi has pointed out that the wiki allows us to leverage clusters. And to use something called transclusion, that allows bits of text to be dynamically included into the wiki pages that you see.
Jodi: a bit of text at the top ... text at the bottom comes from other pages
To Transclude a page, invoke its title like this:
If we want to include category contents, as well as descriptions, we [http://stackoverflow.com/questions/1050853/transclude-a-category-in-mediawiki may need a plugin].
==Category LLD Description==
==Topics we Discussed==
Jodi: citing the name of the page you want to include is enough to trigger text inclusion
<pmurray> This is a nice way to automate the process of brining things together.
Tom: anybody has experience?
<pmurray> This is the first I've seen of this feature of Mediawiki, but I like what it has done.
<Asaf> I have some experience with the feature.
<pmurray> I think some explanatory text at the top of the page on how to edit content on the page would be all that is needed.
Tom:it's interesting. I'm slightly worried about interaction between pages
<digikim> perhaps the transcluded parts could be bigger, "chapter size"...
Tom:... and people looking at the page that's being included in the transclusion page
<jodi>In the edit screen, the pages used (transcluded in) are also linked underneath "Templates used on this page".
Tom: ... we would need one or two owners for the transclusion pages to check that the linking is done correctly
<digikim> from the report point of view, defining the TOC would be a good way to organize this...
Tom: I like it but it looks a little confusing to work with in practice.
Tom: what would be the alternative?
<antoine> ... alternative would be one big page
Tom: anyone have an alternate opinion?
<digikim> antoine: ...or a page divided in ca. 10 transcluded parts
<Asaf> I say let's give it a shot and see how it goes.
<TomB> can you still hear me?
<GordonD> + 1 for transclusion
<AnetteS> +1 for transclusion
<pmurray> +1 to try it; it seems easy enough to try and we can back off to manual processes if it doesn't work
<digikim> +1 for (big part) transclusion :)
<michaelp> +1 for bigger but fewer chunks
Tom: Ed you are skeptical?
Ed: I'm not strongly for or against. Personally I'd personally prefer to focus on the report. I'm not sure it will help write the report
Tom: I'm making the assumption that anything transcluded would be a subsection/paragraph in final report. I don't see us having us products that don't make it in the final report. If a topic has topic page and is transcluded in a discussion page, I'd like this page being transfered into a section with some paragraphs explaining what topics are. Each topic should have someone's attention.
Tom: Everything that has a wiki page transcluded should make it to the report as a paragraph/sub-section
<jodi>it's hard to know what the report will be until we outline it
<edsu> seems like most people were in favor TomB
Tom:Seems we need to move and have an outline of the report
Tom: Jodi, if I understand well it seems that the transclusion is useful for creating a structure. It allows us to re-shuffle an entire section easily.
Tom: almost at the top of the hour. Our next task should be to move towards an outline of the report, to help us focus our attention. We should have a key person for each section
<marcia> I like the way we had today, to focus on one cluster each time
<GordonD> +1 marcia
<edsu> adios :-)