LLD XG -- 10 Mar 2011

<antoine> Previous: 2011-03-03 - http://lists.w3.org/Archives/Public/public-xg-lld/2011Mar/0033.html

<TomB> Scribe: kefo

<TomB> Scribenick: kefo

<rsinger> google talk is currently offering free calls to the US, btw

<pmurray> zakim ??P28 is me

<ww> rsinger: good to know... in my office now, i would guess that the u of edinburgh has a good bulk ld deal so hopefully i won't bankrupt them :)

Admin

TomB: proposes accepting mtg minutes

<ww> +1

[ I missed a lot of that - noise in the room on my end

<ww> an hour earlier is actually better for me :)

<emma> I won't chair on march 24th, Antoine will

TomB: Emma won't chair on 24 march, Antoine will
... moving on to asia pacific telecon
... it's late for many, but happy to accommodate asia pacific participants and thanks to those joining from US and Europe
... Can we identify a scribe?
... Also, goals: we should walk through main agenda points and explain what's going on, how the process is going, encourage participation from them (especially in reviewing sections of the report), and let's leave time to hear from participants who might have something to present or emphasize (topics important to them).
... Will be a informal call.
... Do others have suggestions or comments on this plan?

<antoine> sounds good!

TomB: I'll try to confirm moving the call an our earlier.

Final report draft

TomB: About the executive summary.
... Benefits: Emmanuelle and Ed are working on benefits. Would either like to comment?

Emma: Not started yet, personally.

Are these actions or topics?

Use case and requirements

<TomB> http://lists.w3.org/Archives/Public/public-xg-lld/2011Mar/0038.html

Can topics be "continued?

How to is not the problem. .... Thanks emma

<emma> ACTION: emma and ed to start curating a section on benefits of LLD for libraries [recorded in http://www.w3.org/2005/Incubator/lld/minutes/2011/02/24-lld-minutes.html#action06] [CONTINUES]

<scribe> ACTION: Use cases and requirements (represented via clusters, plus an annotated list of use cases, plus requirement list?) [recorded in http://www.w3.org/2011/03/10-lld-minutes.html#action02]

TomB: We'll have a separate report on use cases. Not too long, but enough.
... Would anyone like to edit this section of hte report?
... You do get to place your name on separate sections (as "editor"), which may be attractive if anyone needs to demonstrate impact of participating in this group/

kcoyle: Do we really need separate documents (one for hte Use Cases)?
... the clusters have been distilled. Perhaps we just need a wiki page to point . I feel we've done this already.

<emma> a report makes it more official for dissemination ?

TomB: I think we have to. But I'd like to formalize it a little. It does not need to be complicated.

kcoyle: I don't see it as a "document" but a "wiki" page because I'd want it linked.

<marcia> Antoine: What did the SKOS do for the usecases?

TomB: I see. No a wiki page is fine. It does not need to be offline.

Antoine: I'd like to comment, also, Marcia asked a question about UC in SKOS.
... We took some of hte Use cases in SKOS and that document linked to other wiki pages . So it was a mix between placing some content in a document and placing some in a wiki.

<TomB> Example of archived wiki page: http://www.w3.org/2006/07/SWD/wiki/Deliverables

Antoine: Regardin Karen's suggestion: A wiki can be edited, making it dynamic, and the W3C cannot archive a Wiki in quite the same way as a "document." They're are labelled as "archived" and no longer actively maintained.

TomB: Here is an example of a frozen wiki page: http://www.w3.org/2006/07/SWD/wiki/Deliverables
... Not going to resolve this unless we have avolunteer.

<scribe> --continues

-- continnues

<scribe> -- continues

I give mup/

<scribe> ACTION: ACTION: Uldis and Jodi to create social uses cluster [CONTINUES] [recorded in http://www.w3.org/2011/03/10-lld-minutes.html#action03]

<emma> Kefo : sent an email to the list that completes the action

<antoine> http://lists.w3.org/Archives/Public/public-lld/2011Mar/0092.html

<TomB> http://www.w3.org/2005/Incubator/lld/wiki/Web_services_on_LLD

<scribe> ACTION: Kevin and Joachim to review content of existing clusters to see where the web service dimension could be strengthened. [DONE] [DONE] [recorded in http://www.w3.org/2011/03/10-lld-minutes.html#action04]

<scribe> ACTION: Available data (vocabularies, datasets) (Antoine and Jeff) [CONTINUES] [recorded in http://www.w3.org/2011/03/10-lld-minutes.html#action05]

TomB: We need to start closing some of these open actions.

<emma> +1 for closing the action

<antoine> +1

<antoine> ACTION: Volunteers to send login information (openid credentials) to William Waite to curate LLD group on CKAN [recorded in http://www.w3.org/2010/11/25-lld-minutes.html#action04] [DONE]

TomB: Main point of call. Gordon's analysis/

PROBLEMS / LIMITATIONS / ISSUES - SECTION IN REPORT

GordonD: Let's concentrate on sections 1 and 3. Section 2 (granularity) can probably be incporated into problems and limitations.

GordonD: we'll being with section 1: Issues for further discussion
... benefits of "Constrained versus unconstrained properties and classes"
... there's been recent disucssion about this on the list.

<GordonD> http://lists.w3.org/Archives/Public/public-lld/2011Mar/0055.html

GordonD: Tom summarized the discussion nicely.
... If we replace direct references to FRBR to something more generic like "library standards" we can get something out of this page,
... Are there any comments on the pros and cons of "Constrained versus unconstrained properties and classes"?

TomB: Are you saying that both are needed? That if you do not have "constrained" properties you will lose information?

GordonD: Yes, that is what I'm saying.

TomB: The value of constrained properties allows for inferencing of more knowledge.

<Zakim> emma, you wanted to suggest getting inspiration from DC

GordonD: Yes. I take the point of unrestrained properties, and I've worked to find a middle ground with some groups.

Emma: I think we can look at DC, where the elements were unconstrained versus later definitions where some ranges are applied.
... Some use the elements because they are unconstrained, others use the constrained terms. But, still, many do not recognize the distinction.

GordonD: I agree. People want and require guidance on this. How does someone choose a set of classes and properties from namespaces. It might be obvious to us, but not others.
... I see a more general guidance piece coming out of this that addresses the mixing and matching and the choices implementers have/

kcoyle: I'm going to question this. I see a far amount of guidance in the unconstrained properties. Take, for example, Work Title. Must that be constrained to FRBR Entity - it already has a clear meaning? It is defined inepdenently.

<emma> +1, Karen : guidance & data constraints are 2 different things

kcoyle: Some analysis should be done. Some *need* to be constrained to have meaning. But others do not.

<antoine> +1

<michaelp> +1

<rsinger> +1

kcoyle: I see constraints as overkill.

GordonD: I disagree. What will happen people will look at hte documentation and will choose a property based on the definition and not its context.

kcoyle: That argues for entity constraints on everything in the sem web.

GordonD: Library data is particularly semantically rich.

kcoyle: I don't know if it is that much different than other data.
... I don;t see the problem, the need to constrain.

jeff_: I tend to agree with GordonD. The constraints help to tell me what they mean (not just how to use them).

<kcoyle> or subclassed to rda without constraints, as in the registry

jeff_: They provide a level of confidence in interoperability. But you can achieve this by constraining the FRBR ontology but sub-classing FRBR classes/properties to DC, for example.

GordonD: Yes. That is the middle ground.
... Use contrained versions where possibe and suitable to protect against data loss, but unconstrained when it matters less.

Antoine: I feel a little uncomfortable with constrained as well.
... We should be careful about the granularity of hte semantics we want with these constraints.

<jeff__> I agree with Antoine on the point of overconstraint

<kcoyle> Here is a place to see RDA properties by entity: http://kcoyle.net/rda/group1propsby.html

Antoine: A benefit of constraints is that I can *infer* knowledge. But, this can be remedied with more expressing facts more explicitly.

<rsinger> +1

<Zakim> TomB, you wanted to point out that SKOS has both constrained and unconstrained properties. The question is: which properties need to be constrained? Hopefully no more than

Antoine: Finally, a practical addition to argument against constraints: you are adding many elements to your namespace.

TomB: When defining SKOS we wanted to keep it as simple as possible. So, some have domains, but others do not. Labelling properties are not restricted only to Concepts. I can be a "preferred label" for abnything you want to use it for.
... We were cautious about restricting domains and ranges in order to facilitate adoption and use.
... If you mechanically replicate properties and classes for *everything* it can lead to a proliferation of classees and properties. Perhaps the constraints should only be used prudently and carefully.

michaelp: My comments follow along the lines of Antoine's and Tom's.
... Constraints tend to be used to specify semantically what we mean. We should be careful about what constraints here mean. In OWL, constraints can negatively impact interoperability because of inconsistency.
... OWL makes assumptions about hte entities based on the properties. It's not *meaning* but "inferencing."

<rsinger> i completely agree with this

<TomB> Michael: we should be careful about what constraints mean. OWL enforces constraints as "inconsistency". Use of X property forces something to considered a "work" (for example). It's not validation, it's inference, so be careful. Much of the constraints should happen on the side of the classes, not with proliferation of properties.

<LarsG> +1 for what michaelp said

<emma> +1, michaelp

jeff_: I appreciate constraints when they make sense.

<ww> validation vs. inference -- validation means applying inference rules to exhaustion and not entailing a contradiction (modulo cardinality and such which didn't work well)

karen: I want to clarify a couple of things. There are alot of levels between constrained and unconstrained RDA.
... We should consider that *some* require constraints. Therefore, not an all or nothing view.
... People are concerned about WEMI Group 1, but less so Group 2 & 3.
... People are concerned about the constraints on WEMI Group 1, but less so Group 2 & 3.
... We should consider constraints applied to application profiles.

GordonD: Communities have invested huge effort into these models. They're well-defined and structured. i"m a little surprised that such rich models are not being welcomed as much as I would have expected.
... We're trying to get general points out of this discussion. The details about the constraints on WEMI, for example, are us talking about the trees and missing the forest.

<Zakim> antoine, you wanted to discuss proposing a modelling exercise

Antoine: Agree with Gordon. We could be talking about any model., not just a FRBR one.
... Could we continue this discussion by a type of modeling exercise? Taking the name and consider its modeling with properties versus classes.

<kcoyle> i would like to see properties v. classes modeled

GordonD: I think this is a good proposal.

<rsinger> maybe in an 88 post email thread ;)

<antoine> :-D

<kcoyle> :-)

TomB: Gordon, bring us home...

GordonD: Application profiles, OWL ontologies.

<LarsG> perhaps we could just have it as an open issue in the final report...

GordonD: Which might be better?

<kcoyle> is this a matter for our report, or a question we want to incubate?

GordonD: Perhaps it would be best to outline the pros and cons to each, which would touch on the constrained versus unconstrained issue.
... There's little agreement about hte *best* approach, but we could provide guidance by outlining the options.

<Zakim> TomB, you wanted to scope what LLD XG can say and what we can identify as a problem

<kcoyle> +1

TomB: I think it's great if we can make some progress on this topic by looking at examples, but it might be unrealistic to provide solutions versus identifying the problem. We nee to be realistic about what we can do, especially in the time reamining.

GordonD: Quickly to section 3, linked data and legacy records
... In many ways this is the flip side of what we were just talking about. Libraries are sitting on mounds of data. Many are beginning to see how opening this up would be beneficial.
... We've had a number of discussions about this and I think we can bring some of these issues in.
... Do others have something to say?

kcoyle: I think legacy data nad the constraint issue come together. Hard to move data into a constrained model.

GordonD: I actually see the existence of constrained properties assisting with providing additional value to legacy data.
... for example, one could output standard MARC records to ISBD, as an initial step, and then, using property/class relationships, move to other namespaces, finally ending on a more FRBR model. But I just thinking out loud.

<kcoyle> and remember that there is a lot of non-library bibliographic data

rsinger: Not seeing how we will bridge the gap between current models/formats and a future one.

GordonD: We do the best we can. history has a way of working these things out.

<rsinger> fair enough

<antoine> ++ for optimistic observation as closing remark :-)

TomB: We need to adjourn. I look forward to talking to others tomorrow to talk about problems and issues.

<LarsG> bye

<ww> thanks !

TomB: Mtg adjourned

<TomB> http://lists.w3.org/Archives/Public/public-xg-lld/2011Mar/0038.html

- DRAFT -

LLD XG

10 Mar 2011

Attendees

Contents

Admin

Final report draft

Use case and requirements

PROBLEMS / LIMITATIONS / ISSUES - SECTION IN REPORT

Summary of Action Items

Scribe.perl diagnostic output