Proposal: add temporal, spatial and physicalDescription to CreativeWork

[mkanzaki]

On working the metadata model for the national archive, which will aggregate data about wide range of cultural heritage objects, it appearers that temporal, spatial and physicalDescription would be useful to describe CreativeWork.

temporal and spatial

While CreativeWork has temporalCoverage and spatialCoverage, these are not sufficient to describe many different aspects of CH objects.

For example, archaeological artifacts have time/place of excavation, or specimens have time/place of collection. Those are not good fit for temporalCoverage and spatialCoverage because these properties are expected to describe "the (focus of the) content".

It would be beneficial for many cases to provide generic temporal and spatial properties, by extending the applicable type (domain) of these properties to CreativeWork from current Dataset.

(original ml post: https://lists.w3.org/Archives/Public/public-schemaorg/2017Oct/0015.html)

physicalDescription

Although schema.org has width, height, numberOfPages, etc. to describe some physical aspects, many CH catalog entries combine those values, e.g. "317 pages ; 21 cm", "26 photographs : black and white" etc. Such values are often hard to parse, and not necessarily match any properties in schema.org if successfully divided.

Simple description could be used, but in many cases, it is desirable to distinguish physical descriptions from content descriptions. MARC has group of Physical Description Fields (3XX), and Dublin Core has format/extent for this purpose.

[RichardWallis]

Closely related to #1759 Already proposed properties to handle 'extent', including some examples relevant to archives, libraries etc. both for compound textual values and potentially more structured description.

~Richard.

[mkanzaki]

@RichardWallis Great to know that there are already substantial proposal for physical description.

My use case is to assign a common property for aggregated datasets, which have varied field names for similar attributes. Sometimes, values are mixture of collectionSize and materialExtent, and not easily differentiated.

Is it possible to merge the physicalDescription proposal to #1759 as a more relaxed property (or possibly super property) of collectionSize and materialExtent ?

[RichardWallis]

@mkanzaki The MaterialExtent & CollectionSize (#1759) proposal could be considered as approaching this issue from the opposite direction.

Chairing both the bibliographic and archives community groups I have seen continued desire for the introduction of an extent property for some time. Due to the lack of consistency in application, and therefore questionable utility in aiding the discovery of items (marked up with strings such as "20 folders + 1 VHS videotape."), only recently a potentially acceptable proposal has taken shape.

The detailed background document on the Schema Architypes Wiki lists some of the many, as you say often difficult to parse, ways that extent is used in archive systems. There are in addition as many uses of this miscellaneous content field in library and other cultural heritage systems.

Although not ideal the proposal attempts to introduce, to those consuming data on the web, at least the possibility of being able descern some structured values. In the specific case of a Collection with a known number of members, the use of collectionSize property is clear. For other extent values where the values can be parsed from existent data, or new data is being created, there is the capability to provide some potentially complex but well structured data. The fallback being to provide a Text value to reproduce what is currently held in legacy systems.

That is a long-winded way of saying that [under the proposal] if you can not parse out the structure in your extent fields, you can always reproduce them as-is in a materialExtent property. I'm still skeptical however how much that will aid discovery, but it might.

What does unsettle me is your suggestion of introducing an even broader scoped property for holding miscellaneous description which encompasses extent - physicalDescription. At least extent is an attempt to describe 'how much' of some thing(s) there are. I believe the subtlety between description and physicalDescription would be lost on most data consumers.

[mkanzaki]

@RichardWallis On reading Wiki extent proposal I guess materialExtent could be used to describe the mixture of collectionSizse and dimensions etc., with Text fallback.

The purpose of my proposal (physicalDescription) is to provide one simple property that covers as much as possible legacy extent related fields. It is not intended to be used for discovery (that needs structured values), but for identification and selection of found items.

If materialExtent can be used for those mixed fields, it's fine. Then I could withdraw physicalDescription proposal. (I'm not sure the English connotation of 'extent')

I once tested to use description for them, but it appeared the distinction between content and physical descriptions helped a lot to understand the metadata, even though not structured.

[ostephens]

"Extent" is definitely a piece of GLAM (or at least Libraries and Archives) jargon, and this meaning of 'extent' would not be immediately obvious to anyone not already familiar with them term in the L/A context.

I'm not in any way against an alternative term being used. Possibly one issue with physicalDescription is that it is too broad. Perhaps it would be worth moving this part of the discussion to #1759 ?

[RichardWallis]

physicalDescription
I agree that we should either remove the physicalDescription proposal from here in favour of the materialExtent proposal #1759, or possibly move this part of the discussion there.

temporal and spatial
Is it being suggested that we consider properties with names such as discoveredLocation, discoveredTimeperiod, excavationLocation, excavatedDate, collectedDate, etc., to be added to CreativeWork? These, plus spacialCoverage and temporalCoverage, becoming sub-properties of spacial and temporal .

[danbri]

Where are we with this?

[RichardWallis]

@danbri
PR (#1784), awaiting merging, handles the basic elements of this as recommended by the Archives group.

Specifically the 'materialExtent' property "The quantity of the materials being described or an expression of the physical space they occupy." is introduced with a domainIncludes of 'CreativeWork' and a rangeIncludes of QuantitativeValue & QuantitativeValue.

I believe that this will be a good start in this area, introducing some descriptive capability which can be be built on at a later date based upon practice and experience.

[mkanzaki]

We still want the applicable types of temporal and spatial to be extended (believing that is beneficial for all). For physicalDescription, we have no preference at this moment.

Background: We no longer plan to include such a detailed property in the metadata model for our national archive. We decided to use much simpler description with leading label of the original metadata term in each value, and let users refer to the the original data for more detail.

[RichardWallis]

Scrolling back, I re-ask my question: Is it being suggested that we consider properties with names such as discoveredLocation, discoveredTimeperiod, excavationLocation, excavatedDate, collectedDate, etc., to be added to CreativeWork?

If that is the case, I think CreativeWork is a too generic a type (with many subtypes) for these properties to make sense in the vast majority of use cases.

They would add valuable information however in certain cases; when things, of potentially any type, have been discovered, collected, or excavated. This leads me to believe the place for such properties would be on the proposed ArchiveComponent type.

[danbri]

Copying in @mkanzaki 's question from #1891,

@danbri How about #1765 ? I don't insist on physicalDescription, but very much want the domains of temporal and spatial to be extended.

@mkanzaki - let's focus on temporal/spatial for now. You are correct that the temporal/spatial-Coverage terms don't give us enough to discuss other spatial or temporal aspects of (many kinds of) item.

Does materialExtent deal with temporal aspects?

[mkanzaki]

@danbri I don't think materialExtent (or physicalDescription) deals with temporal aspects. physicalDescription can be moved/merged to #1759 .

[danbri]

Revisiting this - and congratulations on launching Japan Search - and considering ...

• https://www.kanzaki.com/works/ld/jpsearch/primer/
• https://lists.w3.org/Archives/Public/public-schemaorg/2019Feb/0014.html

is the basic request that "temporal" and "spatial" be amended so that they can apply to any CreativeWork? Looking at those properties it seems temporal is supersededBy temporalCoverage, and spatial by spatialCoverage. Those newer properties are expected for any CreativeWork. Therefore it seems sensible to also allow temporal/spatial to be on CreativeWork too. I think we should make that change.

Having said that, did you consider moving towards eventually using spatialCoverage / temporalCoverage?

[mkanzaki]

Hi, thanks for reply.
The expected values of temporalCoverage and spatialCoverage are stated as "the content applies to", i.e. subjects (about-ness) of the work. As explained in the original proposal, our use case is not limited to the about-ness, but also includes time/place of creation, publication etc.

That is because users tend to search simply something related to a time/place in their mind, not necessarily the subject of the works. Also, it is sometimes difficult to determine whether the place is a subject or something else (e.g. collecting place of specimens or location of filming), especially when mapping aggregated data.

Therefore, it is vital to use generic temporal/spatial for CreativeWorks in our data model, and I believe it would be useful in many cases. It is fine to leave temporalCoverage and spatialCoverage as they are (for explicit about-ness), we just want to relax the domains of temporal and spatial.

Thank you.

[danbri]

Ok, how about this.

Currently we have spatial as the old name for spatialCoverage, likewise temporal and temporalCoverage. The spatial and temporal properties have our old definitions dating from their initial use with datasets, while the newer spatialCoverage and temporalCoverage definitions have been generalized to apply more broadly.

I propose we update "spatial" and "temporal" to remove their (obsolete) focus on datasets, and instead mention the more specific properties that could be used instead, and leave them with a general purpose role for cases where the relationship to place and time is vague.

e.g.

The "spatial" property can be used in cases when more specific properties
(e.g. locationCreated, spatialCoverage contentLocation) are not known to be appropriate.

The "temporal" property can be used in cases where more specific properties
(e.g. temporalCoverage, dateCreated, dateModified, datePublished) are not known to be appropriate.

[vholland]

LGTM

[mkanzaki]

Seems reasonable, I can live with this. Thank you very much for the effort!

[RichardWallis]

Implemented in release 3.5