JiscMail Logo
Email discussion lists for the UK Education and Research communities

Help for DC-COLLECTIONS Archives


DC-COLLECTIONS Archives

DC-COLLECTIONS Archives


DC-COLLECTIONS@JISCMAIL.AC.UK


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

DC-COLLECTIONS Home

DC-COLLECTIONS Home

DC-COLLECTIONS  June 2005

DC-COLLECTIONS June 2005

Options

Subscribe or Unsubscribe

Subscribe or Unsubscribe

Log In

Log In

Get Password

Get Password

Subject:

One-to-one rule (RE: Format of items within collection)

From:

Pete Johnston <[log in to unmask]>

Reply-To:

DCMI Collection Description Group <[log in to unmask]>

Date:

Wed, 15 Jun 2005 11:51:09 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (107 lines)

Andrew said:

> No. Whatever mechanism you choose to do this (If the WG 
> consensus is 'yes') you cannot do it without breaking the 
> fundamental one to one rule. Therefore, in my opinion it 
> SHOULD not be proposed.

Not wishing to subvert the democratic process by continuing to discuss
the issues while the ballot is in progress ;-)

But just to pick up this point... (I made a similar argument to Robina
off-list yesterday)

I think the question comes down to what we want to "say" about the
"world", how we "model" that world, if you like. Whenever we create a
metadata description, we are choosing to say some subset of all the
things we _could_ say about the world, in order to enable a computer
program or a human agent to perform some operation/function using that
information we provide. And often we provide a simplified "view" of what
we know quite well is a more complex reality, because in order to
perform function xyz we only need some particular subset of all the
information we could provide.

So in this case, for example, we need to distinguish carefully between
two (different) sets of information, two different views. 

Consider 

Set (1)
My collection contains the specific items Item:I and Item:J, and the
formats of Item:I and Item:J are mp3 and wav respectively. In this case
(it seems to me) we are clearly describing attributes of those two
specific items and we need to make statements about three distinct
resources.

Collection:C contains Item:I
Item:I is-of-format audio/mpeg
Collection:C contains Item:J
Item:J is-of-format audio/x-wav

Now consider

Set (2)
My collection contains some (unspecified) items of format mp3 and it
also contains some (unspecified) items of format wav. But I'm not
interested in providing any information about individual items. It seems
to me in this case it is quite reasonable to treat the notion of the
collection "having some items of format F" as an attribute of the
collection, and to formulate statements like

Collection:C contains-items-of-format audio/mpeg
Collection:C contains-items-of-format audio/x-wav

This does not (IMHO) break the "one-to-one rule" because we are not
describing the format of specific items; we are explicitly saying that
we will model "having some items of format F" as an attribute of the
collection. 

Now, what would be wrong, I think, would be to use the property
dc:format to represent this relationship, because dc:format is defined
as a relationship between a resource and its own format, not a
relationship between a resource and the format of the items it contains.
So as long as a different property is used to represent this
relationship, I think we can argue that we are working within the
"one-to-one" rule, and not abusing any existing DC properties.

Robina asked me how this compared with, say, expressing the
organisational affiliation of a contributor. My argument was that that
case corresponds to my Set (1) above. Here what you want to say is
indeed that some _specific_ agent has a specific affiliation:

my:book has-contributor Jack
Jack has-affiliation UKOLN
my:book has-contributor Bert
Bert has-affiliation British Library

Now, yes, you could instead make statements analogous to my set B above

my:book has-contributor-with-affiliation UKOLN
my:book has-contributor-with-affiliation British Library

And yes, you _could_ invent a property to do this. But (it seems to me)
those two statements don't represent the information about the world
which you want to convey to your application or human reader. You don't
want to convey the fact that the book has one or more contributors, some
unidentified contributors, affiliated with UKOLN; rather, you want to
say that the book has contributor Jack, and _Jack_ is affiliated with
UKOLN. (There _may_ be some case where you really did just want to say
only "my book has-some-contributor-with-affiliation UKOLN", but I can't
quite grasp what function that would support so I think it would be a
pretty esoteric case!)

But, yes, as several people have said already, it would be good to get
some sense of the Usage Board view on this, because if the UB feels this
is not a reasonable approach, and will reject it when they review the
application profile and/or individual term proposals, then it would be
helpful to know that sooner rather than later. I know several of you are
on this list as individual WG participants, but I'll send some sort of
request for guidance to Tom if that's the best way to consult.

Right, I'll shut up before the electoral monitors come knocking on my
door... ;-)

Pete

 

Top of Message | Previous Page | Permalink

JiscMail Tools


RSS Feeds and Sharing


Advanced Options


Archives

March 2011
November 2010
September 2010
August 2010
May 2010
April 2010
February 2010
September 2009
April 2009
January 2009
July 2008
May 2008
March 2008
January 2008
October 2007
September 2007
August 2007
July 2007
June 2007
April 2007
December 2006
November 2006
September 2006
August 2006
July 2006
June 2006
February 2006
January 2006
December 2005
November 2005
August 2005
July 2005
June 2005
May 2005
April 2005
March 2005
February 2005
January 2005
December 2004
November 2004
October 2004
September 2004
August 2004
July 2004
June 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
February 2003
December 2002
September 2002
August 2002
July 2002
June 2002
April 2002
March 2002
February 2002


JiscMail is a Jisc service.

View our service policies at https://www.jiscmail.ac.uk/policyandsecurity/ and Jisc's privacy policy at https://www.jisc.ac.uk/website/privacy-notice

For help and support help@jisc.ac.uk

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager