RE: Open Items from SIMILE/History System Call Today

> 1. The DSpace system uses CNRI Handles to identify certain 
> objects.  Given that 
> Handles are generally useful for refering to resources, 
> should the Handle refer 
> to the current version of the resource, or to the version 
> current at time of 
> creation?
> Should Handles be used universally to refer to all 
> objects or just 
> those actually retrievable through resolving the Handle?

I offer the following further breakdown of these questions:

1. DSpace assigns handles to (some) resources.
  A. when a handle is assigned, what does it refer to?
     Alternatives include:
	i) "The Work"  ...sorry, FRBR awakes :)
	ii) The current state of "The Work"
      iii) The state of the work at time handle was assigned
	iv) A particular version of some manifestation of the work
	v) some other variant/version/manifestation of "The Work"
	vi) an aggregation of some/all of the above

  if (i) then how are versions and various other manifestations named and resolved?

  if (vi) what mechanism should be used to present the aggregation, and allow inspection/choice among the alternatives.  Choices include (x) application-specific mechanism e.g. Dspace "item overviews" as Dspace does today or (y) some other (perhaps more "standard" or longer-lived) protocol e.g. rddl or the handle system

  Objects/concepts that may require names:
    + "The Work"
    + "The state of the work in a particular situation"
	  e.g.=the state of the work when it was submitted;
	      =the state of the work before transformation;
            =the state of the work after manual correction;
		=the state of the work after 3 cool new viewers were added, thus making the work accessible to a wider audience.

	  state includes content as well as metadata for various manifestations in the scope of "The Work".  In particular I mean state as Harmony uses it, implying that a subgraph of the history data may need to be named for easy reference.

    + "A manifestation of the work"
    + "A version of a manifestation of the work"
	  e.g. versioned bundle of content bitstreams

  B. Given answer to (A) what is appropriate for each handle to resolve to?
	e.g.
	-if a handle refers to "The Work" then it may be appropriate for it to refer to some root graph describing the history/provenance of the work and its various manifestations.  This would have to be returned via some protocol that the handle would map to (for example a Joseki http-based RDQL query).
	- if a handle refers to, say a particular version and desires to map to a particular PDF manifestation, resolution would involve mapping to a DSpace-application-specific URL e.g. http://someDSpaceInstance/.../bitstream/2748

  C. What resources should be assigned handles?

     Corrolary: if resources need to be persistently referred to and they are not assigned handles, then what URI scheme do we adopt?	


> -----Original Message-----
> From: jason_kinner@dynamicdigitalmedia.com 
> [mailto:jason_kinner@dynamicdigitalmedia.com] 
> Sent: Thursday, May 08, 2003 11:38 AM
> To: www-rdf-dspace@w3.org
> Subject: Open Items from SIMILE/History System Call Today
> 
> 
> 
> All -
> 
> We had a good discussion about the initial draft of the 
> History System 
> descriptive note.  Thanks to everyone who participate, by 
> email or by phone.  
> Other than simple errors and omissions, the following topics 
> remain open:
> 
> 1. The DSpace system uses CNRI Handles to identify certain 
> objects.  Given that 
> Handles are generally useful for refering to resources, 
> should the Handle refer 
> to the current version of the resource, or to the version 
> current at time of 
> creation?  Should Handles be used universally to refer to all 
> objects or just 
> those actually retrievable through resolving the Handle?
> 
> 2. When referring to items that are referenced in the current 
> History System 
> output using a database identifier (typically an integer), 
> how should the 
> revised History System refer to them?  The descriptive note 
> recommends URIs in 
> order to capture metadata about the item, but a few ideas 
> were thrown around 
> during the call:
> 
>   a. GUIDs - Every item gets a GUID instead of a database ID
>   b. URNs - Keep the database ID, but make it part of a URN (e.g. - 
> urn:bistream:555)
>   c. URLs - If the resource is accessible via a URL, use the URL
>   d. Handles - See #1, above
> 
> 3. It was offered that the History System might apply the 
> RDF-Schema that 
> defines the object model to perform inferencing on-write, 
> meaning that 
> subproperty values and their parent property values would be 
> stored side-by- side.  This may have an advantage if the 
> query engine (likely to be Joseki in 
> this case) does not support inferencing on its own.  I'd like 
> to ask for 
> comments on whether this may be a good idea.  Some observations:
> 
>   a. The data stored would not be resilient to changes in the 
> schema, requiring 
> a "rebuild" if the schema changes.
>   b. The query engine would not need to be schema-aware at all.
>   c. The query engine would be isolated from changes in the schema.
>   d. The stored RDF models would also be isolated from 
> changes in the schema.
> 
> An issue in #3 is whether isolating stored metadata, which 
> was created in the 
> context of one version of the schema, /should/ inherit 
> changes to the schema.  
> Mark Butler made several valid RDF processing points in a 
> prior post, and that 
> information should probably play into this discussion.
> 
> Thanks again for your feedback.  I will be working on another 
> draft for early 
> next week.
> 
> Regards,
> 
> Jason Kinner
> Dynamic Digital Media, LLC
> 856.296.5711 (mobile)
> 215.243.7377 (phone)
> jason_kinner@dynamicdigitalmedia.com
>

Received on Thursday, 8 May 2003 18:08:35 UTC