Minutes from 16th of May call

Minutes from the 16th of May Telecon:

Attendees: John Erickson, Mark Butler, Kevin Smathers, Rob Tansley,
MacKenzie Smith, Bernard Burg, Jason Kinnear, David Karger (joined late)

MB: Proposed dates for the SIMILE plenaries:
Week of July 22,23,24
(Cambridge, but offsite)
Week of October 21,22,23

MS: Plenaries are a good idea. July dates may be difficult. If you shifted
it to 23 / 24 / 25th. Can't get back before the 23rd. I will be going to UK
following week, might be able to do it in Bristol?

KS: yes, should be able to attend.

JE: The proposed July dates are good. Might have a constraint at the end of
the week, 23rd / 24th are fine.

RT: These dates should be fine.

JK: Fine.

JE: MB and I thought it would be a good idea for labs to host a visit for
Larry Lanham and Christoph Blonky to visit HP labs  in the next three weeks.
Christof would do some kind of presentation, and then there would be some
meeting. This is not  specifically a SIMILE thing, more a HP labs thing, but
the SIMILE team would be more than welcome to participate in the  meeting.
So it would be fruitful for us all to be there. The presentation would be
early morning, so could be transmitted to  Bristol, so everyone local to
Cambridge would be invited. 

Hot topics: naming and the handle system as a dissemination architecture.
I'll have to follow this up with emails to David  and Eric. 

KS expresses interest. Jason Kinnear is coming also. Trying to fix a date
early next week. 

MS: The message I am getting from the community is they don't want to use
handles, so I'm interested to attend, but this may  not mean that we want to
deploy handles. 

DK: I am far away from planning July, so there's nothing there. I can
guarantee not to schedule. The october dates seem clear  of the Jewish
holidays.

I can move to 12.00 at Friday. That's okay. I have more flexibility over the
summer. 

JK: Handles are one of the proposed naming scheme in the history system.
MacKenzie why is there pushback?

MS: Handles are too complicated. Other times handles are already assigned,
so what do we do? But they are confused about how  this is going to work
over the history over the system, different systems, over time etc. 

JK: So to back up, what do you mean by a handle in this context? 

MS: Some of the institutions we are working with have already assigned
handles to things, e.g. a deparment or an institution  gets a handle
namespace. 

KS: The problem is there is no resolution authority for handles.

JK: Resolving it is getting the metadata associated with that handle?

KS: No, its checking they don't conflict.

MS: I just head about it yesterday, so I'm still digesting it. Imagine the
library and the University Press have different  handles, how do we import
from the library to the University Press. DSpace just assumes that
everything is in its namespaces.

JK: Isn't the namespace just for coining names?

RT: Several parts to this: how does DSpace assign handles to incoming
content. Everything ingested into DSpace at the moment  gets a new handle.
There's nothing in the system that precludes multiple naming authorities.
The other tricky bit is a  resolver that can resolve DSpace handles. 

DK: Isn't this just a problem for the Semantic Web e.g. you just say these
URIs are referring to the same thing.

JK: In some sense that may be the responsibility for a higher level schema
or ontology languages.

DK: Well you can use DAML to define equivalence.

JK: So in terms of the history system, this isn't so much of an issue. In
the context of the descriptive note we talk about  DSpace assigning new
handles for use within the history system, primarily as identifiers. One of
the examples is a logo  image, so the history system stores a database that
resolves to the image in someway. However we can't resolve that image
outside the history system. 

DK: This comes back to what is the distinction between a handle and a
content name?

JK: The point is we need a URI, and we can come up with a handle scheme for
URIs, so it seemed to fit. 

MS: So the issue with using the handle as a URI is there is an overhead, due
to the global resolver, but there is no added  advantage to it.

RT: As each DSpace installation has a handle prefix, you can use it so you
don't create resources that conflict with other  dspace installations. 

JK: That's true as the history system solely deals with metadata.

DK: You can get the same effect by using random URIs.

JK: yes but there is an additional issue here about whether we should be
able to resolve this at a later date.

DK: Are the IDs persistant? Handles are supposed to be persistant?

RT: No, not necessarily.

DK: This doesn't bother me in that we are just trying to generate names, but
it does bother me in that we are violating the  handle system.

JK: The other proposal is to use URNs and GUIDs. 

DK: I like the idea that when we have a digitally tangible objects if we
name it with an MD5 hash, but it does push the  resolution off somewhere
else. But at least you can still validate it.

KS: In the security community, the recommendation is to use SHAR not MD5. 

JK: The history system is supposed over time, is hashing going to be
sufficient to prevent naming conclusions?

KS: SHAR is 160 bits, so you are unlikely to see any collision.

DK: It abandons all hope of resolution.

MS: We can always add handles later, I hesitate to add more handles to the
world.

DK: we can only do this for digital objects. 

KS: Also the content can't change, as then the hash changes. 

DK: You need to make an assertion that the following URI has changed, 

That indicates if the content actually changed, or you just copied the same
file in.

DK: Another place I see advantages in using hashes is when we reify. 

KS: Reificiation refers to statings. We had this discussion already - see
issue 68 in the history list.

MS: Can I say a couple of things about the history system descriptive note.
Firstly why are we using the Harmony system? Did  you look at others?

JK: No. Looked at history data, and Harmony model sufficient to model
everything necessary 

MS: What about the object model? Do you mean DSpace object model. 

JK: Statement of work relates just to history system, but could be
ramifications for object model. That should be the next output, the
prescriptive stage.

MS: I have concerns about using Harmony, but if its constrained to the
history system thats not a problem.

MacKenzie: configuration?  Want to be able to customise, turn parts on and
off 

Jason: Part of the statement of work, but not the focus 

MS: Okay, we'll see how it comes out. 

There was some discussion about the history system as an operational thing.
Where is that going to fit into this?

JK: in the statement work it says that there is some configuration work to
be done, we'll probably will do it in the coding  phase. 

MS: Where do you get the collection properties?

JK: Some of the data came from Mick, he discovered additional properties
that I wasn't aware of. 

MS: I should probably hand this to our metadata person to check this is
complete, I suspect you may be missing a few  properties.

JK: I didn't participate in the design, so if there is a design document
here this would be helpful.

Are there other schemas I should be looking at: event modelling no, object
modelling yes.

In theory this should test the SW, as I should be able to use different
models separately. 

MS: I have one other question: in section 3, you are talking about use of
external schemas e.g. Dublin Core and Harmony. 

JK: I mean anything outside DSpace schema. Currently the way the schemas are
used stops other client making use of it. 

I think there is still an issue about whether we should use DC, or whether
we should import it and define the relationship via schema.

MS: So how were you planning to resolve?

JK: My initial plan was to use DC elements externally. 

MS: I'm just try to think ahead to when to when we use schemas that don't
have external references.

JK: one thing is its not clear what usage will be made of the schema after
the information has been created.

I don't think I can address the additional schemas in this round. There
needs to be more work in DSpace to do this.

Jason: Any other models than Harmony to look at? 

MacKenzie: Not for event based, but yes for general object modelling 

Dr Mark H. Butler
Research Scientist                HP Labs Bristol
mark-h_butler@hp.com
Internet: http://www-uk.hpl.hp.com/people/marbut/

Received on Monday, 19 May 2003 10:06:01 UTC