Re: Recommendations: URIs

I'm still trying to get my thoughts straight on this - in the process of
reviewing a (very) basic LD representation of library data at the moment and
I hope this will help clarify my thinking. However, I think I generally
agree with the points made by Ed and Lukas

I wonder if it would help to spell out in more detail what types of things
we think should be prioritised in terms of issuing URIs - I'm slightly
concerned that the terminology can lead to discussions at cross-purposes.
Are there categories of entities we can describe? I'm thinking:

Globally recognised entities - places, people, organisations, etc. - should
use existing URIs where possible
Commonly used (in the library space) controlled vocabularies (not using
'vocabulary' in an RDF/LD sense here) - LCSH, NLMSH, possibly material
types, ??? - should use existing URIs where possible
Locally controlled entities - catalog(ue) records, items - will need to coin
URIs for these

Of course locally you may decided to coin URIs for entities that already
have URIs in the global space, and then make sameAs assertions - so it
doesn't necessarily come down to what you want to do locally and what
happens at a more global level.

Owen


On Wed, Apr 27, 2011 at 10:27 AM, Emmanuelle Bermes <manue@figoblog.org>wrote:

> Right, Ed & Lukas captured my concern very well.
>
> The issue about giving URIs to vocabularies & ontologies, or metadata
> elements sets (not coming back on the definition here ;-) is well
> captured in the recommendations as they are now.
>
> But we need more emphasis on URIs for instance data.
>
> On Wed, Apr 27, 2011 at 10:50 AM, Koster, Lukas <L.Koster@uva.nl> wrote:
> > Interesting subject. I agree with Ed that organisations should try and
> use existing vocabularies & ontologies (by the way, can someone explain the
> difference if there is any? thanks) first.
> >
> > I'll focus on URIs for "instance data" as it is called here. There are 3
> issues here in my mind:
> >
> > - URI syntax schemes: this is a general linked data issue, not a library
> related one. Do you really want to give recommendations  specifically aimed
> at libraries for this? A nice recent article about this:
> http://blogs.talis.com/platform-consulting/2011/04/21/choosing-uris-not-a-five-minute-task/
> >
> > - The "unique" part of URIs: also not a specifically library related
> thing. The http://www.cidoc-crm.org/URIs_and_Linked_Open_Data.html article
> sums it up nicely: central authority, single point of definition. A pity
> that the mentioned links and attachment are missing ;-) But it touches on
> the 3d issue:
>
> Libraries have a story of being concerned with persistence of
> identifiers, which has led to the creation of schemes such as DOI,
> URN, ARK etc. The advantage is to guarantee the central authority. But
> it tends to create undesired complexity. Maybe even if it's a
> non-library problem, we should tell libraries that HTTP URIs are OK if
> they are managed well.
>
> >
> > - Which entities should libraries create URIs for? If we only consider
> bibliographic catalogue metadata, then in my view only really unique
> information would be worthwhile. Looking at the FRBR WEMI structure, it's
> basically only the "I", the Items that libraries own, or rather the holdings
> that libraries can give access to (print and digital). The W, E and M parts
> should ideally be described only once of course. Or at least as less as
> possible (I hope this is correct English ;-) ). Yes, I know this is very
> difficult to achieve, but I think that libraries should try to link their
> holdings to existing trusted Work, Expression and/or Manifestation
> instances/URIs, instead of publishing the same information over and over
> again. This is basically the same task as with Persons and Subjects: using
> authority files.
> > So, this could/should be a recommendation: try to work together as much
> as possible. There are already shared/union cataloguing systems out there,
> so use these. Also the new "next generation ILS" systems (Ex Libris Alma,
> OCLC WMS, Innovative Sierra, Kuali OLE) use this concept of sharing
> metadata. These system vendors should start thinking about this as well. (I
> am doing my best with Ex Libris at the moment).
>
> +1
> Maybe a recommendation that someone should start thinking about how to
> mint URIs for authority data in an authoritative way ? and what would
> be the pattern of such URIs.
>
> I'm still wondering, though, in a Linked Data, bottom-up, open world,
> does such a recommendation makes sense ? As a librarian, I think it
> makes sense. However, if we wait for this to happen, Library Linked
> Data may never happen. We probably need a pragmatic approach.
>
> >
> > Lukas Koster
> > Library Systems Coordinator
> > Library and Information Systems Department
> > Library of the University of Amsterdam
> >
> >
> > -----Original Message-----
> > From: public-lld-request@w3.org [mailto:public-lld-request@w3.org] On
> Behalf Of Ed Summers
> > Sent: Wednesday, April 27, 2011 3:28 AM
> > To: Karen Coyle
> > Cc: public-lld@w3.org
> > Subject: Re: Recommendations: URIs
> >
> > On Tue, Apr 26, 2011 at 8:04 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
> >> Thanks for the comment. It seems to me that you are making a
> >> distinction between ontologies (and value vocabularies) and instance
> >> data -- do I have that right? And that we should emphasize creating
> >> URIs for ontologies FIRST, with URIs for instance data having a second
> priority.
> >
> > Personally, I don't think we should recommend that cultural heritage
> organizations start out with Linked Data by creating ontologies first...much
> the opposite actually. I think the report should encourage the use of
> existing vocabularies & ontologies to publish some of their unique data
> sets, and learn what the gaps and discontinuities are first before creating
> new ontologies.
> >
> > It is already the case that the number of URIs for "instance data" in the
> Library Linked Data space far exceeds the number for vocabulary terms
> (ontologies).  As such I think it deserves the most emphasis. I think your
> section about "Develop policies for namespaces" nicely captures some of the
> issues related to both publishing scenarios.
> > However, the section on registries seems less relevant for instance data.
> >
> > //Ed
> >
> >
> >
>
>


-- 
Owen Stephens
Owen Stephens Consulting
Web: http://www.ostephens.com
Email: owen@ostephens.com