Re: Recommendations: URIs

However, one would not necessarily
> need to give a URI to that _instance_data_ -- unless one
> needed to make statements about it (as in: "this description
> was created by Tom on 2011-04-27").  In other words, I would
> distinguish "statements about instances" and the more specific
> "statements about some instance metadata (itself an instance").

I'm never sure if we're talking about the same things :-). I'll try an  
example:

If I describe a book in LD, I'll want to say things about the book  
(has author, has dissertation-granting institution, has cover color,  
whatever). To do this, I'm assuming I have to have a URI for the book  
so that I can say:

thisBook(URI) -- has author(URI) -- somebody(URI)

I see that as different from describing my ontology using RDF. In that  
case, it's not just a matter of assigning a URI but of creating a  
description (as you said below) with important semantic information --  
information that will inform the creation and use of instance data. I  
guess this could also be seen as the difference between the subjects  
and the predicates in a triple. I believe Emma was saying that we want  
to begin by describing our predicates (and maybe our objects where  
they are controlled value lists).

That's why it seems to be that it's not just that we need *URIs* for  
our ontologies but we need the RDF semantics for them as well as the  
URIs that will identify them. I think that bundling this under URIs  
kind of hides the effort of creating ontologies and makes the  
difference between ontologies and instance data less clear.

That said, I know that on some theoretical level there is not a  
difference between ontologies and instance data. However, I think  
there is a significant different in practice, which makes it desirable  
to work on ontologies for properties first, as Emma says, so that the  
instance data can be created.

I also hear what Ed says about "re-use don't recreate" in terms of  
ontologies. However, when you look at things we call ontologies, like  
BIBO or FOAF, those do re-use where possible. In this sense (and this  
is something I've been meaning to say but then I forget) many  
ontologies are at least in part Application Profiles -- in the sense  
that they are a statement of property selections from the broader  
universe of properties. Tom, I've been meaning to ask you to define  
APs for the report so that we are clear what we mean. I'm assuming you  
mean selection/creation of properties + additional constraints, or  
something like that. In any case, we should make clear what the  
difference is between an AP and an ontology, unless there isn't one.

kc

Quoting Thomas Baker <tbaker@tbaker.de>:

> On Wed, Apr 27, 2011 at 11:38:15AM -0700, Karen Coyle wrote:
>> Something else occurs to me about this. Is it really about assigning
>> URIs to element sets, or is it about defining those element sets in
>> RDF (and also giving them URIs as part of that process)? We will have
>> to use URIs in our creation of instance data if we produce that data
>> in RDF, but we won't be registering an RDF definition of those many
>> millions of items.
>
> The fourth of Tim Berners-Lee's "five stars of linked open
> data" [1] is "Use URLs to identify things, so that people
> can point at your stuff".  Another way to put it might be:
> "Name things of importance (in your world) using URLs".
>
> The fifth star is "Link your data to other people's data
> to provide context".  Another way to put it might be: "Make
> interesting statements about your things, such as how they
> relates to, or are contextualized by, other people's things".
>
> My sense is that "using URLs to identify things" in the broad
> sense should indeed come first, as above [1].  Things _should_
> be identified by URLs before they become the subjects of
> RDF statements.
>
> By "RDF definition of...  items", I think you mean "RDF
> statements about things".  If so, then I would argue that
> the first step would be to "name" the things about which
> statements will be made; this is done by identifying them
> with URIs.  Then those things can be "defined" (in the sense of
> "describe") by making statements about them.
>
>> It might be that we want to FIRST create RDF definitions of our
>> properties and value vocabularies, THEN create instance data, but both
>> get URIs, don't they?
>
> If you use URIs to identify the things ("instances") you want
> to describe, and then you describe those instances using RDF
> statements, those descriptions (sets of statements) could be
> seen as "instance data".  However, one would not necessarily
> need to give a URI to that _instance_data_ -- unless one
> needed to make statements about it (as in: "this description
> was created by Tom on 2011-04-27").  In other words, I would
> distinguish "statements about instances" and the more specific
> "statements about some instance metadata (itself an instance").
>
> I'm not sure if this is helpful...
>
> Tom
>
> [1] http://inkdroid.org/journal/2010/06/04/the-5-stars-of-open-linked-data/
>
>> Quoting Emmanuelle Bermes <manue@figoblog.org>:
>>
>> > Dear Karen & everyone,
>> >
>> >Thank you for starting this very important discussion on
>> >recommendations. This is going to be one of the most important parts
>> >of the final report of the group, so let's hope there will be a lot of
>> >comments - or only confirmation of aproval, from both people from the
>> >group and others (that's why we chose to discuss the recommendations
>> >on the community list, so everyone, feel free to comment).
>> >
>> >Regarding URIs...
>> >It seems to me that there are 2 different things here :
>> >- assigning URIs for metadata elements sets in due time, and declaring
>> >them in registries so that they can be discovered and managed
>> >- policy / guidelines / patterns for assigning URIs to resources
>> >(instances).
>> >
>> >In the Benefits section, we put strong emphasis on URIs being one of
>> >the main advantages of Linked Data, because URIs provide means to
>> >uniquely identify and link to works, places, people, events, etc.
>> >I think that it's not exactly the same thing to design URIs for
>> >metadata elements and for resources such as works, places, people,
>> >events, etc. For example, what would mean "assigning URIs in due time"
>> >when speaking about resources such as works, authors, books, documents
>> >? 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 ?
>> >
>> >Il also wanted to point to the recent recommendation on museum URIs
>> >from the Cidoc [1].
>> >
>> >Emma
>> >
>> >[1] http://www.cidoc-crm.org/URIs_and_Linked_Open_Data.html
>> >
>> >
>> >
>> >On Fri, Apr 22, 2011 at 6:16 PM, Karen Coyle <kcoyle@kcoyle.net> wrote:
>> >>There has been a small group working on defining the LLD Issues[1] for our
>> >>report, followed by the Recommendations[2]. Since these are both long and
>> >>complex wiki pages, we felt it would be better to post individual topics
>> >>for
>> >>discussion here on the list (although it would probably be a good idea for
>> >>everyone to give a quick glance at the ToC of each page to get an overview
>> >>and context for the discussion).
>> >>
>> >>To start, here are three recommendations relating to use of identifiers
>> >>and
>> >>in particular URIs, that we can discuss as a unit:
>> >>
>> >>
>> >>*Create URIs for library resources in good time*
>> >>
>> >>Library data cannot be used in a linked data environment if URIs for
>> >>specific resources and the concepts of library standards are not
>> >>available.
>> >>The official owners of resource data and standards should assign URIs in
>> >>good time, as application developers and other users of such data will not
>> >>delay their activities. They are more likely to assign URIs themselves,
>> >>outside of the owning institution. When owners are not able to assign URIs
>> >>in good time, they should be prepared to allow others to do so, to avoid
>> >>proliferation of URIs for the same thing and encourage re-use of URIs
>> >>already assigned.
>> >>
>> >>*Develop policies for namespaces*
>> >>
>> >>Organizations and individuals who create and maintain URIs for resources
>> >>and
>> >>standards will benefit if they develop policies for the namespaces used to
>> >>derive those URIs. Policies might cover
>> >>
>> >>   * Use of patterns to design URIs, based on good practice guidelines.
>> >>   * Persistence of URIs.
>> >>   * Good practice guidelines and recipes for constructing ontologies and
>> >>structured vocabularies.
>> >>   * Version control for individual URIs and the namespace itself.
>> >>
>> >>*Declare namespaces and URIs in metadata registries*
>> >>
>> >>Owners of namespaces will benefit if they declare URIs and associated data
>> >>in one or more metadata registries, although this is not a requirement for
>> >>effective use of linked data. Registries make it easier for potential
>> >>users
>> >>to find, identify, select, and obtain URIs for their own applications.
>> >>They
>> >>can store information about a namespace as a whole, including intended
>> >>audience, context, and ownership. Registries may provide additional
>> >>facilities for maintaining a namespace, including editing screens, version
>> >>control, and change notification. Registries bring namespaces from
>> >>different
>> >>sources together and help encourage mixing and matching of URIs to suit
>> >>specific purposes, and thus encourage re-use of existing URIs.
>> >>
>> >>-----
>> >>
>> >>Please post any comments, suggestions, etc., that you have!
>> >>
>> >>kc
>> >>
>> >>[1] http://www.w3.org/2005/Incubator/lld/wiki/Draft_issues_page
>> >>[2] http://www.w3.org/2005/Incubator/lld/wiki/Draft_recommendations_page
>> >>
>> >>--
>> >>Karen Coyle
>> >>kcoyle@kcoyle.net http://kcoyle.net
>> >>ph: 1-510-540-7596
>> >>m: 1-510-435-8234
>> >>skype: kcoylenet
>> >>
>> >>
>> >>
>> >
>> >
>>
>>
>>
>> --
>> Karen Coyle
>> kcoyle@kcoyle.net http://kcoyle.net
>> ph: 1-510-540-7596
>> m: 1-510-435-8234
>> skype: kcoylenet
>>
>
> --
> Tom Baker <tbaker@tbaker.de>
>
>



-- 
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 19:53:52 UTC