Consider how to support additional metadata for newspapers use case

[zimeon]

Issue date and article category are used as facets in display in CDNC for example

http://cdnc.ucr.edu/cgi-bin/cdnc?a=q&hs=1&r=1&results=1&txq=oranges&txf=txIN

[jpstroop]

Date is important for building a calendar view. Doesn't need to be typed or anything, just need to know which entry to grab from the bucket/pail. #438 Might be an alternative to building out a service.

[jpstroop]

Also need things like page number, word count, article title, byline, etc. All of these can go in the metadata pool on their corresponding Ranges.

[jpstroop]

Proposal from tech mtg @ GW: import dcterms:date as sortDate, which can appear (practically) anywhere, for use driving calendars, timelines, and the like. Justification for creating a semantic property is that it is useful for sorting in the above use cases.

[azaroth42]

I propose "viewingDate" to align with viewingHint, viewingDirection.

viewingDate
: A date that the client can use when presenting the resource to the user in a time based user interface, such as a calendar or timeline.

• A manifest MAY have a viewing date.
• A sequence MAY have a viewing date.
• A canvas ... use case? Canvas that represents the state of the depicted object at a certain time, and other canvases have different times?

Cardinality -- SHOULD have at most 1? Or multiple just means it will appear multiple times in the timeline? (some nasty duration hack?)

[anarchivist]

From the changes in 898f98a (linebreaks added for readability):

viewingDate
:    A date that the client can use when presenting the resource to the user in a time-based user 
interface, such as a calendar or timeline.  The value _MUST_ be an xsd:dateTime literal, of the 
form "YYYY-MM-DDThh:mm:ssZ".  If the exact time is not known, then 00:00:00 _SHOULD_ be used.  

Does this mean that only UTC as expressed with the timezone as Z is valid, or are timezones expressed as valid offsets according to xsd:dateTime also valid?

[azaroth42]

I would restrict it to only UTC to avoid requiring clients to do
complicated timezone math across different institutions' manifests.

On Wed, May 13, 2015 at 1:32 PM, Mx A. Matienzo notifications@github.com
wrote:

From the changes in 898f98a
898f98a
(linebreaks added for readability):

viewingDate
: A date that the client can use when presenting the resource to the user in a time-based user
interface, such as a calendar or timeline. The value MUST be an xsd:dateTime literal, of the
form "YYYY-MM-DDThh:mm:ssZ". If the exact time is not known, then 00:00:00 SHOULD be used.

Does this mean that only UTC as expressed with the timezone as Z is
valid, or are timezones expressed as valid offsets according to
xsd:dateTime also valid?

—
Reply to this email directly or view it on GitHub
#442 (comment).

Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305

[zimeon]

+1 to requiring UTC in Z form
cardinality 0 or 1 -- don't allow any duration hacks as would likely break simple implementations

[jpstroop]

I don't really like "viewingDate" though. I can't quite put my finger on why, but some quick thoughts:

1. "viewingHint" and "viewingDirection" feel different to me. They're both a controlled set of strings that really have to do with how the resource itself might be displayed. This date has as different type, and is exclusively about the resource in the context of other resources.
2. Does this really need to be a date at all? What about other types of periodicals that have, e.g. vol x, issue y? Maybe we should broaden and have something like "sortIndex" and stay silent about the type. ISO dates would still sort lexically as long as they had consistent precision (right?).
3. It it could suggests (though it's not true according other ways we've used viewingX' and the fact that it's listed as a technical property--maybe we just need to make it a bit more technical; cf. point 3) that this date is meant to be displayed. Whatever. Respect the Model. Fine.
4. Why can any resource have this property? Are there use cases beyond Manifest? Would one ever need to sort Sequences, Layers, Ranges... by date? I can stretch to imagine use cases, but are they real?

Assuming we stick with a date, I think I'd be more comfortable with just "date", which would align it more closely with "width" and "height", or maybe "sortDate", since that's what it's really about.

[azaroth42]

Okay, granted it's not quite the same as the other viewing properties. How about navigationDate or (shorter) navDate? That's the purpose of the date after all, and would establish a pattern between properties intended for navigation to the object versus the rendering/view[ing] of the object?

Following 4. we don't have any use case for non dates, and if it's not a date just sortable, it wouldn't fulfill the calendar or timeline use cases we do have. So re 2. yes I think it does, as the interval between dates is important, not just the order.

And I buy the argument that we don't have any real use cases for resources other than Manifest and Collection [e.g. collection of the 3 editions of a newspaper on a single day, with a date but no time]. The reason I thought to make it optional everywhere was that in the table at the end, we would have to put "not allowed" ... which then seems like a breaking change to make it optional in the future? Or is that okay if in 2.2 we allow it on, say, Ranges?

[zimeon]

I also think our use cases are for a date specifically (not just an order).

Re. naming: I like "sortDate" but "navDate" also. I agree that "viewingHint" and "viewingDirection" feel different

Imagine a diary, one day per page, with multiple volumes.... I can see dates on Collection, Manifest, Range... Canvas? IMO adding MAY on another object in 2.2 is not a breaking change however (ref: #470)

[jpstroop]

OK. I figured if I asked for a bunch of stuff I'd get what I most wanted 😏.

+1 to "navDate" or "sortDate" with a slight preference for the former as it reflects our intentions the best (IMO).

[jpstroop]

Closed by ae5f1df