Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: add temporal, spatial and physicalDescription to CreativeWork #1765

Closed
mkanzaki opened this Issue Oct 8, 2017 · 18 comments

Comments

Projects
None yet
5 participants
@mkanzaki
Copy link

commented Oct 8, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2017

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

This comment has been minimized.

Copy link
Author

commented Oct 8, 2017

@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

This comment has been minimized.

Copy link
Contributor

commented Oct 8, 2017

@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

This comment has been minimized.

Copy link
Author

commented Oct 9, 2017

@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

This comment has been minimized.

Copy link

commented Oct 9, 2017

"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

This comment has been minimized.

Copy link
Contributor

commented Oct 9, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2018

Where are we with this?

@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

@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

This comment has been minimized.

Copy link
Author

commented Mar 2, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Mar 2, 2018

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

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2018

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

This comment has been minimized.

Copy link
Author

commented Jun 12, 2018

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

@danbri

This comment has been minimized.

Copy link
Contributor

commented Mar 1, 2019

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

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

This comment has been minimized.

Copy link
Author

commented Mar 2, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Mar 8, 2019

LGTM

@mkanzaki

This comment has been minimized.

Copy link
Author

commented Mar 9, 2019

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

RichardWallis pushed a commit that referenced this issue Mar 21, 2019

Removed superseded status from and generalised descriptions for spat…
…ial and temporal properties plus expanded their range to CreativeWork.

Issue #1765.

danbri added a commit that referenced this issue Mar 21, 2019

Removed superseded status from and generalised descriptions for spat…
…ial and temporal properties plus expanded their range to CreativeWork. (#2181)

Issue #1765.
@RichardWallis

This comment has been minimized.

Copy link
Contributor

commented Apr 10, 2019

Implemented in release 3.5

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.