W3C home > Mailing lists > Public > public-xg-lld@w3.org > February 2011

Re: Brainstorming: Key Issues

From: Emmanuelle Bermes <manue@figoblog.org>
Date: Wed, 23 Feb 2011 10:02:07 +0100
Message-ID: <AANLkTinxZp5jmENghwcVhO1ZAEUxjyF1avzwSLib2KSZ@mail.gmail.com>
Cc: "public-xg-lld@w3.org" <public-xg-lld@w3.org>
M 2 cents for the brainstorming :

1) What's the impact of Linked Data on current systems ? there are
different scenarios or different steps. Linked Data can be first
implemented just as another protocol for exposing the data (like for
instance OAI-PMH) : thus with little impact on systems and production
processes. Or, Linked Data can imply to re-think completely the way we
model, produce and use our data : a revolution. Does our group have
any recommendation or comments on these different perspectives ?

2) Library systems and Linked Data  - should all library systems adopt
Linked Data ? Does it make any sense at all that every library exposes
their own data ? Does Linked Data imply to have more centralized
systems, where most of the data is mutualized ?

3) Linked Data standards and MARC - going back to question 1, we can
envision Linked Data as another interoperability framework that will
come in addition to source formats (Dublin Core never replaced MARC,
but still, it's useful to exchange data with other communities). Is
RDF really a candidate to replace MARC ? In what timeframe ? What does
it mean for legacy data : is it possible to convert it without loosing
information ? what tools are needed to do so ? is it possible to share
them ?


On Wed, Feb 23, 2011 at 9:32 AM, Antoine Isaac <aisaac@few.vu.nl> wrote:
> On 2/22/11 11:30 PM, Karen Coyle wrote:
>> Quoting Antoine Isaac <aisaac@few.vu.nl>:
>>> + Need to carefully articulate library value vocabularies (concepts,
>>> terms) with real world entities they stand for. Library entities are
>>> "proxies" for real things, which linked data has as core focus. Perhaps this
>>> needs some education of the LD community, ie, convince them that there is
>>> any value in having such proxies. And identifying appropriate mechanisms
>>> (ie. efficient in terms of data creation and consumption) to represent this
>>> (a-la skos:Concept + foaf:focus)
>> I'll add this in, but I'm not sure you'll get consensus on this one. Or at
>> least, there will be differences in what people assume is the "real thing"
>> being represented. E.g. library catalog entry is seen by some as a surrogate
>> for the book; the subject headings are thus part of the surrogate for the
>> book, not representatives of real world objects -- thus topic "Eiffel Tower"
>> in catalog entry represents the topic of book, not the tower itself.
>> We could spend the rest of our time on this question, so perhaps it should
>> be introduced in the document as a question that needs to be answered,
>> rather than an answer that needs to be accepted.
> Yes, but I think this will be the case for many issues in our report, won't
> it?
> Note that here all I would be expecting is a brief
> description/examplification of the problem. A bit as you did; by RWO I meant
> only the Eiffel Tower itself indeed. The point is that the general linked
> data crowd finds it quite unnatural that "topics" should be given their own
> life as resources next to the RWO ones.
> So we'd need to explain:
> - the legacy aspects (millions of "topics" are there),
> - the benefits of the approach (especially, it would be cleaner for data
> management and alignment)
> - and some hints at how to handle it with SW tech in a way that still make
> some sense for the common data consumer, as Jeff did in his mail (on way
> could be indeed to advocate that "topics" representations should be aligned
> with RWO representations, as much as possible).
> It can remain quite shallow (I would not expect here a theory on the notions
> of "surrogate" or "proxy") as long as it demonstrates well enough the
> importance of the problem.
> Can such an approach fit what you have in mind for this "issues"? Or do you
> think such a paragraph (I think it can be as small as the above) would be
> too big already?
> Antoine
Received on Wednesday, 23 February 2011 09:02:39 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:35:56 UTC