LLD XG -- 11 Nov 2010

<Asaf> reconnecting in a minute.

<TomB> Previous: http://www.w3.org/2005/Incubator/lld/minutes/2010/11/04-lld-minutes.html

<ww> Zakim: ??P6 is me

<TomB> Anette, take a look at http://www.w3.org/2005/Incubator/lld/Scribing.html to prepare...

<TomB> Scribe: jodi

<AnetteS> thanks, Antoine

<TomB> Scribenick: jodi

Administrative

<antoine> minutes are actually good!

TomB: Propose that we accept last week's minutes. Apologies for technical difficulties.

<ww> +1

Resolved: To accept the minutes of previous teleconference

CKAN for datasets

<ww> 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.
... 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.

<edsu> ww++

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 would be an alternative starting point.

<marcia> +1 ww

more on CKAN and LLD: http://blog.okfn.org/2010/09/03/next-version-of-the-linked-open-data-cloud-based-on-ckan/

Antoine: Karen, Jonathan, Ed, and others are admins for the CKAN Bibliographic group.

Ed: Two questions: 1) Bibliographic group on CKAN now is not specifically about LD - just bilbiographic data in general

<Asaf> but here's an example from that group: -> http://ckan.net/package/hungarian-national-library-catalog

Ed: 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 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, etc

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

<GordonD> Non-bibliographic linked data of interest: circulation data, library location and directory data ...

<edsu> jodi: http://richard.cyganiak.de/2007/10/lod/lod-datasets_2010-09-22_colored.html ?

<Zakim> TomB, you wanted to ask whether a dataset is "in" one group or another, or merely referenced?

Antoine: We're interested in bibliographic, but we are not only interested only in bibliographic data. We want to be an included group, ie. we include everything in the LOD cloud. Want to include the bibliographic data group. What are the tech limitations of CKAN? Can we include everything into the LOD cloud?

edsu: thanks, the light green is the part I wanted to point out there. :)

<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 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.

<edsu> tomb++

<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?

Authority data

<antoine> GordonD+ - that's what I'd like to have with "tagging" LOD sets with something like a "LLD" tag

TomB: Jeff and Alexander - assess progress on analyzing the clusters. How far have we gotten?
... 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.
... 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. Other one: enrichment--more of a meta case.

s Jeff: Enrichment is nice: to explore what these use cases have in common. SKOS a nice level of abstraction -- naming.

Jeff: 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.
... 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 ones.
... 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 records.
... 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.

<Asaf> GordonD++

Jeff: How this gets represented as a product of our (Alex+my) understanding. There's some danger of our imagining what they are doing, without enough detail.
... 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 is.
... 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?

<antoine> +1

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.

Use Case Methodology

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.

http://www.w3.org/2005/Incubator/lld/wiki/Transclusion_Test

<antoine> Jodi: a bit of text at the top

<antoine> ... text at the bottom comes from other pages

To Transclude a page, invoke its title like this: <nowiki>{{:Use Cases}}</nowiki>. You can get more info from [http://www.mediawiki.org/wiki/Transclusion MediaWiki help].

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==

<antoine> 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.

<antoine> +1

<antoine> TomB: 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.

<antoine> TomB: it's interesting. I'm slightly worried about interaction between pages

<Asaf> pmurray++

<digikim> perhaps the transcluded parts could be bigger, "chapter size"...

<antoine> ... and people looking at the page being included in the transclusion page

In the edit screen, the pages used (transcluded in) are also linked underneath "Templates used on this page".

<antoine> ... 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.

<antoine> TomB: what would be the alternative?

antoine, k, thanks! :)

<antoine> ... alternatice would be one big page

<antoine> TomB: anyone having alternative opinion?

<digikim> antoine: ...or a page divided in ca. 10 transcluded parts

<antoine> +1 for transclusion

<Asaf> I say let's give it a shot and see how it goes.

<TomB> can you still hear me?

yes

<digikim> yes

<marcia> yes

<GordonD> + 1 for transclusion

<AnetteS> +1 for transclusion

<antoine> +1 (again)

<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

<antoine> TomB: Ed you are skeptical?

<antoine> edsu: I'm not strongly for or against

<antoine> ... personally I'd personally prefer to focus on the report

<antoine> ... I'm not sure it will help write the report

<antoine> TomB: I'm making the assumption that anything transcluded would be a subsection/paragraph in final report

<antoine> ... I don't see us having us products that don't make it in the final report

<antoine> ... if a topic has topic page and is transcluded in a discussion page

<antoine> ... I'd like this page being transfered into a section with some paragraphs explaining what topics are

<antoine> ... we should have each topic having the attention of someone

<antoine> ... everything that has one wiki page transcluded should make it to the report as a paragraph/sub-section

it's hard to know what the report will be until we outline it

<edsu> seems like most people were in favor TomB

<antoine> TomB: Seems we need to move and have an outline of the report

<antoine> ... Jodi, if I understand well it seems that the transclusion is useful for creating a structure

<antoine> ... allows to re-shuffle entire section easily

<antoine> Jodi: yes

<antoine> TomB: almost at the top of the hour. Our next task should be to move towards an outline of the report

<antoine> ... to help us focus our attention

<antoine> ... 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

<antoine> [ADJOURNED]

<digikim> thanks

<AnetteS> bye

<edsu> adios :-)

<digikim> antoine: thanks for the email(s); we are very busy but try to help out with LLD, too -- too many projects going on and no "official" resources for LLD work :)

<antoine> digikim: I understand!

<antoine> ...it's great that you are still around!

<digikim> it's great to be involved, just would like to give a more substantial input :)

- DRAFT -

LLD XG

11 Nov 2010

Attendees

Contents

Administrative

CKAN for datasets

Authority data

Use Case Methodology

Summary of Action Items

Scribe.perl diagnostic output