Re: Proposal to extend the domains of temporal and spatial

Thanks for quick reply.

> "spatialCoverage" is better modeled as a specialized subproperty of
> "spatial" (and same for temporal(Coverage)) ?

Ah, well, given that spatialCoverage is sub-property of
contentLocation and temporalCoverage is just a property in current
model, reorganization seems make sense.

cheers,


2017-10-08 0:27 GMT+09:00 Dan Brickley <danbri@google.com>:
> I like the idea of improving this and addressing your use case. From a
> quick look it seems that we have marked 'spatial' and 'temporal" as
> being superseded by the corresponding *Coverage properties. Perhaps
> that is a mistake that we made and we should distinguish the different
> kinds of relationship that things can have to places/times. Maybe
> "spatialCoverage" is better modeled as a specialized subproperty of
> "spatial" (and same for temporal(Coverage)) ?
>
> Dan
>
> On 7 October 2017 at 16:10, KANZAKI Masahide <mkanzaki@gmail.com> wrote:
>> Hell everyone,
>>
>> I'd like to propose to extend the applicable type (domain) of
>> schema:temporal and schema:spatial to CreativeWork (or possibly to
>> Thing) from current Dataset.
>>
>> Background and rationale:
>> I'm now designing the metadata model for the national archive, which
>> will aggregate data about wide range of cultural heritage objects.
>> While CreativeWork has temporalCoverage and spatialCoverage, these are
>> not sufficient to describe many different aspects of CH objects (See
>> issue #1803[1] for background of these properties).
>>
>> 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".
>>
>> Rather than minting every new properties e.g. temporalExcavation, it
>> would be beneficial for many cases to provide generic temporal and
>> spatial properties. Leave current temporalCoverage and spatialCoverage
>> as they are, which would be still good for standard content
>> description.
>>
>> Would that be reasonable? Your comments and/or suggestions are welcome.
>>
>> best regards,
>>
>> [1] https://github.com/schemaorg/schemaorg/issues/1083#issuecomment-233043971
>>
>>
>> --
>> @prefix : <http://www.kanzaki.com/ns/sig#> . <> :from [:name
>> "KANZAKI Masahide"; :nick "masaka"; :email "mkanzaki@gmail.com"].
>>



-- 
@prefix : <http://www.kanzaki.com/ns/sig#> . <> :from [:name
"KANZAKI Masahide"; :nick "masaka"; :email "mkanzaki@gmail.com"].

Received on Saturday, 7 October 2017 15:42:08 UTC