Re: Recommendations: URIs

> On Wed, Apr 27, 2011 at 4:24 PM, Thomas Baker <tbaker@tbaker.de> wrote:
>> I think we're agreeing that "assigning URIs" is a key point
>> but that for the sake of readers we need to distinguish "URIs
>> for properties and classes" from "URIs for dataset items
>> (instances)".
>
> Nicely put Tom. I second Jeff's recommendation to at least reference
> ABox and TBox to ground the more library friendly definitions wherever
> that may happen: glossary, etc.
>


What's funny (maybe not 'ha ha' funny) is that I thought that's what I  
was saying when I talked about 'ontologies' v. instances. And the ABox  
and TBox pages made no sense to me at all. So I guess we are still  
struggling with our own terminology.

OK,  now that we are here, which one are we recommending? That  
libraries concentrate on ontologies, or that they concentrate on  
identifying their "things"? And do you consider the entries in VIAF to  
be "things" in that sense? (Just so we've got a real life example.)

Emma said:

"Designing persistent, trusted URIs for resources: shouldn't that be
the first requirement for creating a Linked Data project ? Aren't
there cases where it is better to mint local URIs for resources,
rather than re-use existing ones ?
So wouldn't it be useful to make a distinction between assigning &
maintaining URIs for metadata standards, and designing URIs for a
particular dataset ?"

Ed said:

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

Lukas said:

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

Emma replied:

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

Owen stated:

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

Ed answered:

"I agree with Owen: it would be very useful if the recommendations
provided guidance about the types of resources that cultural heritage
organizations should consider making available as Linked Data. Perhaps
this is going to be covered in another section of the recommendations,
and it can be referenced in the URIs section?"

It seems to me that we've covered a wide range of topics here. I added  
a sentence to the section "Develop policies for namespaces" reading:

* In keeping with the principles of the semantic web, promote the use  
of URLs for the identification of library elements, vocabularies and  
bibliographic data.

We can obviously change the wording. But I still am not sure what we  
are promoting in terms of prioritizing the creation of URIs. Can we  
use Tom's wording?

"Very broadly, the "library world", along with standards
developers such as W3C, FOAF, and DCMI should work on assigning
URIs to properties and classes.  But creators of specific
Linked Data projects should be concerned first and foremost
with _creating_ URIs for their things -- the "instances" about
they want to make statements -- then re-use URIs for properties
and classes (when possible) in order to make those statements."

kc

Quoting Ed Summers <ehs@pobox.com>:

> On Wed, Apr 27, 2011 at 4:24 PM, Thomas Baker <tbaker@tbaker.de> wrote:
>> I think we're agreeing that "assigning URIs" is a key point
>> but that for the sake of readers we need to distinguish "URIs
>> for properties and classes" from "URIs for dataset items
>> (instances)".
>
> Nicely put Tom. I second Jeff's recommendation to at least reference
> ABox and TBox to ground the more library friendly definitions wherever
> that may happen: glossary, etc.
>
> //Ed
>
>



-- 
Karen Coyle
kcoyle@kcoyle.net http://kcoyle.net
ph: 1-510-540-7596
m: 1-510-435-8234
skype: kcoylenet

Received on Wednesday, 27 April 2011 21:31:04 UTC