JeromeDL/StructureRelations

From Corrib Clan Wiki

RDF Schema of resource structure doesn't provide all the information. We can't find there relations between elements if some of subjects are given particular values. This information is very important when we are talking about GUI for resource upload. When we choose a value for one entry it is possible that some options in following form should disappear or should be changed. This shows that understanding a semantic of a resource type is the point.

Purpose of this wiki page is to answer following questions:

• what are possible resource types?

as explained in the email - I would like to consider resource types as deprecated
  

• which fields should be available for editing? and when?

the only exclusion I see is that chapter can contain PDF, XSL:FO or collection of pages - since all of them can be described as resources 
I would suggest introducing RDF classes like (PdfResource, XslFoResource, ImageCollection::rdf:Seq)::ChapterResource
So I think in the current approach we do not need to hide anything - but the default view should contain only one chapter with PDF, while user should be  
able to add chapters, media parts, attachments, etc.

• how fileds change when some of elements are given different values?

they do not have to
 

/!\ add concepts from JIRA: category+, keyword+, institute+, project+, workingroup+, etc. /!\

...to be continues

from RDFS we know about some classes:BR notation:

• Class [ :Class ]
  • property(DataType) [ possible values ]
  • property
  • ...

• File
  • description(Literal)
  • content(Resource) [rdf | xsl:fo | (x)html]
  • mimeType(Literal)
  • fileSrc(Literal)

• SequencedFile :File
  • position(Literal)

• XslFoSource
  • href(Literal)
  • content(Resource) [rdf | xsl:fo | (x)html]

• Chapter
  • content(Resource) [rdf | xsl:fo | (x)html]
  • name(Literal)
  • page(SequencedFile)
  • position(Literal)
  • title(Literal)
  • pagesRangeFrom(Literal)
  • pagesRangeTo(Literal)

• MediaPart :Chapter
  • width(Literal)
  • height(Literal)
  • scaleToFit(Literal)
  • thumbnail(File)
  • contentSmaller:content(File)

and we know some information about relations (context insensitive):

• Book:
  • cover(File)
  • digitalType(ResourceType) [pdf | scan | swf | uri | xslfo]
  • href(Literal)
  • mediaPart(MediaPart)
  • preprint(Literal)
  • previousVersion(Book)
  • protectionType(Literal) [accessOnly | payPerView | protectFromCopying | protectFromPrinting]
  • abstract(Literal)
  • allowedTo(Literal)
  • attachement(SequencedFile)
  • bookType(BookType) [article | book | booklet | conference | deliverable | inbook | incollection |

inproceedings | manual | masterthesis | misc | oldbook | phdthesis | proceedings | publications | script | techreport ]

• • chapter(Chapter)
  • published(Literal)
  • updateDate(Literal)
  • uploadDate(Literal)
  • uploadedBy(Resource)
  • usageCount(Literal)
  • versionNumber(Literal)

Assume that each Book and class can have all listed properties. It is not a true of course so lets create all possibilities. Proposed notation:

• Book:
  • ...
  • digitalType = uri
  • href

• Book:
  • ...
  • digitalType = pdf
  • -href (minus href, href is not available beceuse user chose pdf digital type previously)

Order in which properties apper apply to order in which user provided information. Another idea is to describe how properties behave if particular input is provided, which input fields are available for all types of resource, which fields can change situation, when multi-file upload is necessary and so on ...