See also: IRC log
<antoine> Previous: 2011-03-03 - http://lists.w3.org/Archives/Public/public-xg-lld/2011Mar/0033.html
<TomB> Scribe: kefo
<TomB> Scribenick: kefo
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 we're happy to accommodate Asia-Pacific
participants and thanks to those joining from the US and
Europe
... Can we identify a scribe for the Asia-Pacific telecon?
... Also, goals for the telecon: 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 hour earlier.
TomB: About the executive
summary.
... Benefits: Emmanuelle and Ed are working on benefits. Would
either like to comment?
Emma: I've personally not started yet.
<scribe> Use cases and requirements (represented via clusters, plus an annotated list of use cases, plus requirement list?)
<TomB> http://lists.w3.org/Archives/Public/public-xg-lld/2011Mar/0038.html
ACTION: emma, TomB, and antoine to send a call for finding an owner of the UC deliverable [recorded in http://www.w3.org/2005/Incubator/lld/minutes/2011/02/24-lld-minutes.html#action07] [DONE]
TomB: We'll have a separate
report on use cases. Not too long, but enough.
... Would anyone like to edit this section of the 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 the Use Cases)?
... The clusters have been distilled. Perhaps we just need a
wiki page to point to. I feel we've done this already.
<emma> a report makes it more official for dissemination ?
TomB: I think we have to. 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.
TomB: I see. No a wiki page is fine. It does not need to be offline.
<marcia> Antoine: What did the SKOS do for the usecases?
Antoine: I'd like to comment,
also, Marcia asked a question about UC in SKOS.
... We took some of the 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 volunteer.
<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] [recorded in http://www.w3.org/2005/Incubator/lld/minutes/2011/02/10-lld-minutes.html#action13]
<scribe> Available data section (vocabularies, datasets) (Antoine and Jeff) -- CONTINUES
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.
GordonD: Let's concentrate on sections 1 and 3. Section 2 (granularity) can probably be incporated into problems and limitations.
<antoine> http://www.w3.org/2005/Incubator/lld/wiki/Library_standards_and_linked_data
GordonD: We'll begin with section
1: Issues for further discussion,
... the 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 DC elements namespace properties 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 independently.
<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 the documentation and they 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. You can find a middle ground 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 the 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 also be remedied by 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, I would like to submit 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 properties have domains,
but others do not. Labelling properties are not restricted only
to Concepts. You can use a "preferred label" for anything 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 the entities based on the
properties. It's not *meaning* but "inferencing." It's also not validation.
<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 fully constrained and completely
unconstrained RDA models.
... We should consider that *some* properties/classes require constraints.
Therefore, not an all or nothing view.
... 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. I would have expected such
rich models to be more welcomed than thay appear to have been.
... 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 of each, which would touch on the
constrained versus unconstrained issue.
... There's little agreement about the *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 need 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 and 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'm just thinking aloud.
<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 future ones.
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