Using xsd:date, too, in the model?

[iherman]

At present, the lifecyle information restricts to the usage of xsd:dateTime. However, in practice, it may be (sometimes) a drag to have to specify this down to the seconds; wouldn't it be possible to allow for the usage of xsd:date as a possible alternative? A client may recognize the date format after all...

[azaroth42]

I'm not in favor. If there is an option for multiple formats, then it would be advantageous to have those formats explicit. But that means using the JSON-LD @value/@type pattern: {"@value": "2016-01-19", "@type": "xsd:date"} ... which means explaining it and the inevitable confusion between value/@value and type/@type. If it's not explicit anywhere, then we'll end up with garbage in there.

[iherman]

I'm not in favor. If there is an option for multiple formats, then it would be advantageous to have those formats explicit. But that means using the JSON-LD @value/@type pattern: {"@value": "2016-01-19", "@type": "xsd:date"} ... which means explaining it and the inevitable confusion between value/@value and type/@type. If it's not explicit anywhere, then we'll end up with garbage in there.

True, there is a danger for garbage. But there is also a (possibly higher) danger of people using only dates, without time when the time section is meaningless. Better be prepared by making this official.

We can make it explicit in the text for the model. In the vocab we can do something more complex. We can even use OWL to define some sort of a derived datatype.

[akuckartz]

Maybe dcterms:W3CDTF can be used? Popolo and OpenGovLD do that.

[iherman]

On 22 Jan 2016, at 20:36, Andreas Kuckartz notifications@github.com wrote:

Maybe dcterms:W3CDTF can be used? Popolo and OpenGovLD do that.

I must admit I did not know about this stuff:-) but it may indeed do the trick…

Here is the formal definition:

http://dublincore.org/documents/dcmi-terms/#terms-W3CDTF http://dublincore.org/documents/dcmi-terms/#terms-W3CDTF

[stain]

With lifecycle informaton, is it oa:sourceDate we are talking about?

Please don't use dcterms:W3CDTF - that is an after-effect of the XML aspects of Dublin Core and just becomes really weird in RDF - aka a new "Date" resource is created which must then have its own value specified somehow - adding yet another value property to the mix. (See page 10 of http://co.mbine.org/specifications/omex.version-1.pdf#page=10 )

Perhaps add a second JSON-LD key for the same property, which has defined @type: xsd:date? sourceDate and sourceDateTime?

[stain]

The RDFS definition of dcterms:W3CDTF shows it as a rdfs:Datatype - so it would indeed be valid to use it @type on a literal (and wrong to use it as a property as COMBINE did)

dcterms:W3CDTF
    dcterms:hasVersion <http://dublincore.org/usage/terms/history/#W3CDTF-003> ;
    dcterms:issued "2000-07-11"^^<http://www.w3.org/2001/XMLSchema#date> ;
    dcterms:modified "2008-01-14"^^<http://www.w3.org/2001/XMLSchema#date> ;
    a rdfs:Datatype ;
    rdfs:comment "The set of dates and times constructed according to the W3C Date and Time Formats Specification."@en ;
    rdfs:isDefinedBy <http://purl.org/dc/terms/> ;
    rdfs:label "W3C-DTF"@en ;
    rdfs:seeAlso <http://www.w3.org/TR/NOTE-datetime> .

aka it could be any of these:

   Year:
      YYYY (eg 1997)
   Year and month:
      YYYY-MM (eg 1997-07)
   Complete date:
      YYYY-MM-DD (eg 1997-07-16)
   Complete date plus hours and minutes:
      YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00)
   Complete date plus hours, minutes and seconds:
      YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00)
   Complete date plus hours, minutes, seconds and a decimal fraction of a second
      YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00)

It would still be confusing without specifying deeper how to use dcterms:W3CDTF as the DC Terms page is not very helpful.

[iherman]

On 25 Jan 2016, at 17:44, Stian Soiland-Reyes notifications@github.com wrote:

The RDFS definition of dcterms:W3CDTF shows it as a rdfs:Datatype - so it would indeed be valid to use it @type on a literal (and wrong to use it as a property as COMBINE did)

dcterms:W3CDTF dcterms:hasVersion http://dublincore.org/usage/terms/history/#W3CDTF-003 ; dcterms:issued "2000-07-11"^^http://www.w3.org/2001/XMLSchema#date ; dcterms:modified "2008-01-14"^^http://www.w3.org/2001/XMLSchema#date ; a rdfs:Datatype ; rdfs:comment "The set of dates and times constructed according to the W3C Date and Time Formats Specification."@en ; rdfs:isDefinedBy http://purl.org/dc/terms/ ; rdfs:label "W3C-DTF"@en ; rdfs:seeAlso http://www.w3.org/TR/NOTE-datetime . aka it could be any of these:

Year: YYYY (eg 1997) Year and month: YYYY-MM (eg 1997-07) Complete date: YYYY-MM-DD (eg 1997-07-16) Complete date plus hours and minutes: YYYY-MM-DDThh:mmTZD (eg 1997-07-16T19:20+01:00) Complete date plus hours, minutes and seconds: YYYY-MM-DDThh:mm:ssTZD (eg 1997-07-16T19:20:30+01:00) Complete date plus hours, minutes, seconds and a decimal fraction of a second YYYY-MM-DDThh:mm:ss.sTZD (eg 1997-07-16T19:20:30.45+01:00) It would still be confusing without specifying deeper how to use dcterms:W3CDTF as the DC Terms page is not very helpful.

As a very very practical point: all usual time libraries ("moment" library for Javascript, built in datetime facilities for python, etc) have functions/methods to handle all those various date formats, both for parsing and for generating. It looks a little bit silly if we force the user to use only one of those if there is a way to handle the union of those properly.

If we want to be on the very formal side in RDF land, we could look at the OWL2 datatype creation facilities whether that can be used, ie, to define a new datatype properly. But, at least at first glance, this W3CDTF does work for me...

[stain]

The danger of dcterms:W3CDTF is that it has historically been used also as a class, e.g. as in 2.3.13 of http://dublincore.org/documents/dcq-rdf-xml/

dcterms:modified [ a dcterms:W3CDTF; rdf:value "2010-04-06" ]

[iherman]

The danger of dcterms:W3CDTF is that it has historically been used also as a class, e.g. as in 2.3.13 of http://dublincore.org/documents/dcq-rdf-xml/

To be honest, I did not even know this thing existed:-). I think it is a minor danger.

[stain]

OK, @iherman, you have won me over - consider my vote +0 :) for dcterms:W3CDTF as a literal @type (enforced by the JSON-LD context so you won't need the @value)

[iherman]

Telco, 2016-02-05: http://www.w3.org/2016/02/05-annotation-irc#T16-55-53

Adopt dc:W3CDTF as feature-at-risk, to fall back to xsd:datetime. Recommend full ISO8601 form.

[azaroth42]

In starting to write this up I ran into a problem ... we use prov:generatedAtTime for generated, and it has an explicit range of xsd:dateTime (https://www.w3.org/TR/prov-o/#generatedAtTime)

In order to consistently adopt w3cdtf, we would need to avoid the use of generatedAtTime. The range of created and modified are rdfs:Literal, which does work with w3cdtf.

Perhaps we could use dcterms:issued for generated? http://dublincore.org/documents/dcmi-terms/#terms-issued (and keep the generated json key) Retagging as telco.

[iherman]

On 19 Feb 2016, at 20:08, Rob Sanderson notifications@github.com wrote:

In starting to write this up I ran into a problem ... we use prov:generatedAtTime for generated, and it has an explicit range of xsd:dateTime (https://www.w3.org/TR/prov-o/#generatedAtTime https://www.w3.org/TR/prov-o/#generatedAtTime)

In order to consistently adopt w3cdtf, we would need to avoid the use of generatedAtTime.

I am not so concerned. It is a balancing act: do we want to make use of the Prov vocabulary in general or not? If yes, than we can live with this inconsistency.

The range of created and modified are rdfs:Literal, which does work with w3cdtf.

Perhaps we could use dcterms:issued for generated? http://dublincore.org/documents/dcmi-terms/#terms-issued http://dublincore.org/documents/dcmi-terms/#terms-issued (and keep the generated json key) Retagging as telco.

If we do not want to to stick with the prov vocabulary, that this indeed a good alternative.

I think this is a minor issue that we may be able to handle by email, without using telco time (let us reserve telco for the tougher issues…)

[azaroth42]

We use three prov terms at the moment, if we want to remove prov completely we could use the following mapping:

prov:generatedAtTime --> dcterms:issued prov:wasGeneratedBy --> as:generator prov:SoftwareAgent --> as:Application

I would be :+1: to this change... prov has caused us nothing but headaches :( (Note that as also has as:published, but it has an explicit range of xsd:dateTime)

[iherman]

fine with me

On 22 Feb 2016, at 19:04, Rob Sanderson notifications@github.com wrote:

We use three prov terms at the moment, if we want to remove prov completely we could use the following mapping:

prov:generatedAtTime --> dcterms:issued prov:wasGeneratedBy --> as:generator prov:SoftwareAgent --> as:Application

I would be to this change... prov has caused us nothing but headaches :( (Note that as also has as:published, but it has an explicit range of xsd:dateTime)

[akuckartz]

@azaroth42 Sad to read that prov created headaches :-(

The range of as:published potentially can still be extended to dcterms:W3CDTF /cc @jasnell

[azaroth42]

Thus the proposal on the table is:

"generated" maps to dcterms:issued, currently prov:generatedAtTime "generator" maps to as:generator, currently prov:wasGeneratedBy "Software" maps to as:Application, currently prov:SoftwareAgent

All date times (created, modified, generated) are to be W3CDTF, with at-risk status to fall back to xsd:dateTime, and a recommendation to use the full ISO8601 form whenever possible.

[iherman]

Discussed the extension to the issue around the prov ontology on telco 2016-02-26; agreement to use AS instead of PROV

See: http://www.w3.org/2016/02/26-annotation-irc#T16-43-31