search

schemaorg / suggestions-questions-brainstorming

Suggestions, questions, and brainstorming
19 stars 15 forks source link

query re: Duration #105

Open SignpostMarv opened 5 years ago

SignpostMarv commented 5 years ago

Is Duration a Thing or a DataType?

All the examples I'm seeing feature DataType as a specifically-formatted string, ala Date, Time, and DateTime.

thadguidry commented 5 years ago

Duration is actually a Thing (Type). https://schema.org/Duration Why? Because it can have several properties.

Duration:

The Paleozoic Era could be modeled alternatively from an Event as a REALLY long duration for instance. Where lots of things were formed during it, like the Carboniferous System.

We don't have all of these properties that I mention above currently, but many of them could be proposed if needed.

What is your use case? :-)

SignpostMarv commented 5 years ago

@thadguidry ah- the properties aren't listed under schema.org- are those properties in an unreleased version?

thadguidry commented 5 years ago

They are in my version. :-)

Schema.org is an evolving standard. Currently as it stands, Duration is simply a quantity that is formatted in ISO 8601 duration format. There are no properties other than those borrowed from Thing itself.

SignpostMarv commented 5 years ago

@thadguidry ah :)

my use-case is "making a very daft implementation in PHP"- if Duration is a Thing, then class Duration extends Thing{}, but if it was a data type then it'd be class Duration extends DateInterval{}

vholland commented 5 years ago

@thadguidry I am not sure I am following the logic here. All of your proposed properties could be served by a DataType. Given the other ISO 8601 values (Date and DateTime) are DataTypes, it seems like Duration should be as well.

thadguidry commented 5 years ago

@vholland Do you subscribe to the thought that a DataType is still a Type in Schema.org ?

All I am saying is that Duration could be/and often is synonymous with a TimeSpan, Period, Length, etc. and where there are potentially many properties that could be used/proposed. There is much more that other models/schema say regarding Spans of Time.

vholland commented 5 years ago

No, I would say they are literals (in the OWL sense).

thadguidry commented 5 years ago

@vholland Then in that case, we are missing a lot of useful Spans of Time "Types" like Period, Era, etc. that could include Duration. Currently, Spans of Time have to be Events in Schema.org, and some folks just don't really like making all Spans of Time as Events because they are typically considered shorter Spans of Time. We have these conversations in other issues currently actually, but I'm too lazy to find them now.

Era: Paleozoic Era

vholland commented 5 years ago

@thadguidry Yes. I can't find it now, but we have discussed adding schema for eras, etc.

But that is different than saying something like "this video is 5 minutes long", which is best served by the existing Duration schema.

SignpostMarv commented 5 years ago

@thadguidry would this not work for y to x million years ago ?

{
    "@context": "http://schema.org",
    "@type": "QuantitativeValue",
    "minValue": -544,
    "maxValue": -245,
    "unitText": "million years"
}
thadguidry commented 5 years ago

@SignpostMarv Yes, that's how you would have to do it, but it can't be done with ISO 8601 duration format.

thadguidry commented 5 years ago

@vholland I know, I'm just telling @SignpostMarv that in MY version, I have a parent Duration type that I use to classify many kinds of durations with those common properties and for me its a Thing. We in Schema.org don't have them, that's fine. We in Schema.org will probably move them into individual Types for different Spans of Time, and that's fine also. How we come together or if we pull in some other schema like owl-time is yet to be decided. But since the owl-time effort made by Spatial Data Web Working Group (that includes some scientists), I'd imagine that we would very much appreciate their years-long efforts on owl-time and perhaps eventually treat it as we did with GS1.

If you replace my Duration mentioned above with the term Era: then it probably makes more sense of what I am talking about. (My Duration =~ yours and Owl-Time's Era's, Periods, etc.)

Era:

...and for my cases, owl-time doesn't take it far enough for kinds of Intervals and Temporal Entities regarding provenance/metadata. They kind of just gave up and said...nope, out-of-scope for us. Stuff like this: The term "Palaeozoic" was coined by the British geologist Adam Sedgwick (1785–1873)

MichaelAndrews-RM commented 5 years ago

@thadguidry I'm curious if anything will change when the Extended Date/Time Format (EDTF) Specification (ISO 8601-2019 Part 1 and ISO 8601-2019 Part 2) is published in mid 2019.
It allows for a duration to be specified as an interval:

e.g., ‘2004-06-XX/2004-07-03’ also, it permits durations to be listed as "sub-year groupings", such as Quadrimester 1 (4 months in duration) or Spring - Northern Hemisphere.

It will be a big change, though maybe not a quick one to catch on.

thadguidry commented 5 years ago

@MichaelAndrews-RM you are asking if we will change anything in Schema.org? dunno.

vholland commented 5 years ago

Personally, I am a big fan of EDTF. With that said, what we do here is limited until data readers are willing to support EDTF in addition to legacy 8601 strings.

SignpostMarv commented 5 years ago

@MichaelAndrews-RM @vholland were it not for sub-year groupings, this still makes sense for Duration to be a DataType rather than a Thing.

danbri commented 5 years ago

I can see a case for Duration being closer to DataType than its current home, "Thing > Intangible > Quantity > Duration". That said, what is broken by leaving things as-is?

rvguha commented 5 years ago

Interval is a data type. Duration (like mass, volume, etc.) is a Quantity. Quantities are typically a measurement unit + data type.

We should add Interval as a data type.

guha

On Tue, Jan 29, 2019 at 10:14 AM Dan Brickley notifications@github.com wrote:

I can see a case for Duration being closer to DataType than its current home, "Thing > Intangible > Quantity > Duration". That said, what is broken by leaving things as-is?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/schemaorg/schemaorg/issues/2117#issuecomment-458647560, or mute the thread https://github.com/notifications/unsubscribe-auth/AFAlCmvkcC2DZXAVPV2aRXmLxIzRFXJsks5vII-RgaJpZM4ZoqTi .

SignpostMarv commented 5 years ago

@danbri it's not so much a case of it being broken as "does any existing schema.org implementation have a duration that appropriately uses any property of Thing?".

If no appropriate use is found, then the question follows "does any conceivable use-case require a Duration to have Thing properties that is not better suited to some other thing that uses Duration as a value?".

If the answer to both questions was "no", then this implies Duration is best suited as a DataType that can be concisely represented in a given language with whatever native or userland implementation that can parse, modify and otherwise support a reasonable portion of the ISO 8601 duration spec.

tl:dr; if Duration is a DataType, supporting parsers can perform quick validations of "is it an ISO 8601 duration string?", rather than "is it an ISO 8601 or a thing that has it's own potentially endless list of properties that need to parsed & validated?".

thadguidry commented 5 years ago

Re: Duration... even @jbkoh didn't know how our Duration maps to QUDT in https://github.com/schemaorg/schemaorg/issues/1390#issuecomment-290835465 , but I found it just now... a Duration in QUDT 2.0 is basically a measurement captured on a qudt:RatioScale

Here is how Duration combines both a measurement ("9,192,631,770") & unit ("periods") as @rvguha explains:

The second is the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium 133 atom.

Re: Interval , @rvguha are you talking just Interval or IntervalScale ?

qudt:IntervalScale
  rdf:type owl:Class ;
  qudt:description """<p>The interval type allows for the degree of difference between items, but not the ratio between them. Examples include temperature with the Celsius scale, which has two defined points (the freezing and boiling point of water at specific conditions) and then separated into 100 intervals, date when measured from an arbitrary epoch (such as AD), percentage such as a percentage return on a stock,[16] location in Cartesian coordinates, and direction measured in degrees from true or magnetic north. Ratios are not meaningful since 20 °C cannot be said to be \"twice as hot\" as 10 °C, nor can multiplication/division be carried out between any two dates directly. However, ratios of differences can be expressed; for example, one difference can be twice another. Interval type variables are sometimes also called \"scaled variables\", but the formal mathematical term is an affine space (in this case an affine line).</p>
<p>Characteristics: median, percentile &amp; Monotonic increasing (order (&lt;) &amp; totally ordered set</p>"""^^rdf:HTML ;
  qudt:description "median, percentile & Monotonic increasing (order (<)) & totally ordered set"^^rdf:HTML ;
  rdfs:isDefinedBy <http://qudt.org/2.0/schema/qudt> ;
  rdfs:isDefinedBy <http://qudt.org/schema/qudt> ;
  rdfs:label "Interval scale" ;
  rdfs:seeAlso qudt:NominalScale ;
  rdfs:seeAlso qudt:OrdinalScale ;
  rdfs:seeAlso qudt:RatioScale ;
  rdfs:subClassOf qudt:Scale ;
  skos:prefLabel "Interval scale" ;
  prov:wasInfluencedBy <https://en.wikipedia.org/wiki/Level_of_measurement> ;
SignpostMarv commented 5 years ago

also, stupid question; if Duration is a Thing, on which property does it go on if it is represented as a Thing and not as an ISO string?

RichardWallis commented 4 years ago

See issue #7 for the context of the move from the main Schema.org issue tracker to this repository.