Differences between revisions 1 and 2
Revision 1 as of 2008-06-26 12:26:04
Size: 6260
Editor: kfc
Comment: Created by the PackagePages action.
Revision 2 as of 2010-03-17 13:09:20
Size: 6400
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
''This page was imported from'': [http://hera/cgi-bin/viewcvs.cgi/*checkout*/DOMS/Ingest/design/discussionPaper.tex?rev=HEAD discussionPaper.tex] by [:mke: mke] ''This page was imported from'': [[http://hera/cgi-bin/viewcvs.cgi/*checkout*/DOMS/Ingest/design/discussionPaper.tex?rev=HEAD|discussionPaper.tex]] by [[mke]]
Line 3: Line 3:
''Author'': [:bam: bam] ''Author'': [[bam]]
Line 12: Line 12:
On the page [:DOMS_objects:] three basic On the page [[DOMS objects]] three basic
Line 25: Line 25:
[#fig figure 1] illustrates relations between objects. The [[#fig|figure 1]] illustrates relations between objects. The
Line 29: Line 29:
[[Anchor(fig1)]]
[[ImageLink(http://merkur/viewvc/trunk/docs/legacy/logo1example.png?root=doms&view=co)]]
[[BR]] [[BR]]
[[ImageLink(http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.png?root=doms&view=co)]]
<<Anchor(fig1)>>
[[http://merkur/viewvc/trunk/docs/legacy/logo1example.png?root=doms&view=co|{{http://merkur/viewvc/trunk/docs/legacy/logo1example.png?root=doms&view=co}}]]
<<BR>> <<BR>>
[[http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.png?root=doms&view=co|{{http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.png?root=doms&view=co}}]]
Line 34: Line 34:
Figure 1. The 'logo1' ingest example 'from a distance' and an image object 'close-up'. Original xfig sources [http://merkur/viewvc/trunk/docs/legacy/logo1example.fig?root=doms&view=co here] and [http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.fig?root=doms&view=co here]. Figure 1. The 'logo1' ingest example 'from a distance' and an image object 'close-up'. Original xfig sources [[http://merkur/viewvc/trunk/docs/legacy/logo1example.fig?root=doms&view=co|here]] and [[http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.fig?root=doms&view=co|here]].
Line 46: Line 46:
[:DOMS_Content_Model:]): [[DOMS Content Model]]):
Line 69: Line 69:
The page [:SB_DOMS_object_structure:] suggests: The page [[SB DOMS object structure]] suggests:
Line 115: Line 115:
This is suggested on the page [:SB_DOMS_object_structure:]. This This is suggested on the page [[SB DOMS object structure]]. This

This page was imported from: discussionPaper.tex by mke

Author: bam

DOMS Objects and Object Structure Discussion

The current (Tue Nov 21) object design and structure choices are presented briefly and a number of questions are raised.

DOMS Objects

On the page DOMS objects three basic objects, 'Group', 'Entity' and 'Atom', are suggested. Are there differences which merit a definition of different DOMS objects? Should such 'top level object types' be defined in the 'contentModel' property (in current example all objects have contentModel 'SBOBJECT')?

There is also a question of 'ordered groups', e.g. pages in a book. There are a number of possible solutions for this...

Example objects

The 'logo1' ingest example data/ingest2Test/ in figure 1 illustrates relations between objects. The image object 'close-up' illustrates the contents of a DOMS object with type image.

http://merkur/viewvc/trunk/docs/legacy/logo1example.png?root=doms&view=co

http://merkur/viewvc/trunk/docs/legacy/imageObjectExample.png?root=doms&view=co

Figure 1. The 'logo1' ingest example 'from a distance' and an image object 'close-up'. Original xfig sources here and here.

DOMS Content Model

The content model defines the content of one DOMS object. Different types have different content models. Types are also DOMS objects and all DOMS objects reference a type using the 'isObjectType' relation - except the 'type type object'?

SB Objects

All objects are 'SB objects' and contain (see DOMS Content Model):

  • Properties

    • type = "FedoraObject"

    • state = "A"

    • label

    • contentModel = "SBOBJECT"

  • Datastreams

    • Dublin Core

    • Relations

      • hasRights

      • isObjectType

    • Administrative

  • Disseminators

    • ?VIDEO_PRESENTATION (start, maxMilliSecs) -> MPEG2

    • ?SOUND_PRESENTATION (start, maxMilliSecs) -> MP3

    • ?IMAGE_PRESENTATION (maxWidth, maxHeight) -> PNG

    • ?TEXT_PRESENTATION (start, maxChars) -> UTF-8 TXT

    • Index Representation -> XML

The 'Fedora Object Dublin Core datastream' is specified where? The 'SB Object Dublin Core datastream' should be specified.

The page SB DOMS object structure suggests:

  • Additional datastreams

    • ?PRESENTATION_IMAGE_150x150

    • ?PRESENTATION_IMAGE_700x700

    • ?PRESENTATION_IMAGE_FULL

    • ?PRESENTATION_MOVINGIMAGE_PREVIEW

    • ?PRESENTATION_MOVINGIMAGE

    • ?MASTER

Type Objects

Type is a subtype of SB (type type exception)?

  • Additional datastream

    • Type

The 'type datastream' is yet to be defined. The type SB (all types subtypes of type SB) should be predefined (missing in example). Which other types should be predefined? Suggestions: type type, type project, type rights, type file, type logical, type image, type audio, type video, type text, type filetype (all filetypes subtypes of type filetype?), certain filetypes?

Would we like all type objects to have 'isObjectType relation' to type type and introduce a 'subtype relation' (self reference issue again)?

Rights Objects

Rights is a subtype of SB (hasRights exception)?

  • Additional datastream

    • Rights

      • seeInIndex

      • seeObject

      • accessContent

      • modifyObject

The 'rights datastream' should be defined.

Non-Project Objects

  • Datastreams

    • Additional relation

      • isPartOfProject

This is suggested on the page SB DOMS object structure. This suggests an 'SB project' for types and rights objects. Perhaps the 'isPartOfProject relation' should be defined for logical objects?

File Objects

  • Datastreams

    • Additional relations

      • isFileType

      • ?hasOriginal

  • Additional datastreams

    • Content

    • Technical

Image/Audio/Video/Text Objects

  • Datastreams

    • Additional relations

      • ?has...File

Questions

  • PID The left side should be a known project; these should be specified in Fedora properties; right side should be? Object renaming?

  • contentModel =SBOBJECT for all objects in example; should this be changed to 'top-level types'?

  • Dublic Core Language? Should format and rights be described in DC as well as in RELS-EXT? Last Thursday we talked about letting the Fedora Dublin Core be a simple 'title-holder' and then introduce an SB Dublin Core datastream. Why was that and should we?

  • RELS-EXT How do we avoid self-references in a nice way? Does 'object type type' not have an 'isObjectType' relation? Do all type objects not have an 'isObjectType' relation? How many 'isObjectType' relations can one object have? Do we have a 'subType' (or a more general 'conceptualParent') relation? Repeat the above questions with right objects and 'hasRights'. Is the 'isPartOfProject' relation mandatory for all non-project objects (including types and rights) -- do we have an SB project for types and rights? Should the 'isPartOfProject' relation be mandatory for file objects (if we expect these to be referenced by multiple logical objects)? Do we want an explicit 'isFileType' relation in file objects or do we want to use the 'isObjectType' for file-type as well?

TODO

  • Datastreams Rights: Usage rights (if I can access the material, what can I use the material for)? Creative Commons machine readable rights? Type datastream (type objects). Technical datastream (file objects).

  • Syntax pages (for doms-relations, administrative, rights, type and technical datastreams)

ActionSalvageDataModel/DOMSObjectStructureDiscussion (last edited 2010-03-17 13:09:20 by localhost)