Time stamp compatibility

[ajnelson-nist]

I have some use cases involving multiple properties that can represent the "Same" timestamp, but happen to have specifications that slightly disagree on the datatype to use, especially xsd:dateTime vs. xsd:dateTimeStamp. Sometimes, these properties are in different specifications - that matter is a bit moot, though, because I can't change the specification(s).

Because RDF doesn't have "Subdatatype" like it has "Subclass" and "Subproperty," this is a compatibility issue if I ever want to try to port the "Same" timestamp from one of the properties to another.

E.g., take this graph:

PREFIX ex: <http://example.org/>

ex:p-dt
  a rdf:Property ;
  rdfs:range xsd:dateTime ;
  .

ex:p-dts
  a rdf:Property ;
  rdfs:range xsd:dateTimeStamp ;
  .

ex:Thing-1
  ex:p-dts "2020-01-02T03:04:05-06:00"^^xsd:dateTimeStamp ;
  .

If I want to derive this triple ...

ex:Thing-1
  ex:p-dt "2020-01-02T03:04:05-06:00"^^xsd:dateTime ;
  .

... my understanding is I currently have to step into SPARQL to use STRDT in a CONSTRUCT query.

And, there is an extra check needed to go from xsd:dateTime to xsd:dateTimeStamp, to confirm that the timestamp has a time zone. I'd prefer to not construct the triple, rather than construct a triple with an errant literal.

This seems like something that should be doable with a node expression, with a touch of sh:pattern. Is there design in place, or planned, on re-typing literals?

[ajnelson-nist]

FWIW, I think the discussion in #160 is a separate matter from this Issue.

[afs]

XSD has its own concept that related datatypes. xsd:dateTimeStamp is a derived datatype of xsd:dateTime ("derived" means more restrictive in some facet(s)). This XSD "derive" is the opposite direction from the example.

If there is a timezone, a Functions & Operators cast works otherwise the lexical form needs fixing (string concat a timezone).

There is a similar situation between xsd:Duration and xsd:dayTimeDuration and alsoxsd:yearMonthDuration (and theer isn't a case between the latter two).

This also looks like a case of "default value" which is a variation of "derived/computed property" -- only add if a triple is missing. For xsd:dateTime there is only one way (well, almost) to write the literal. For other datatypes, there may be multiple ways to write a literal and just computing may end up with multiple triples with the same value. e.g. xsd:decimal : "1", "1.", "1.0", "+1.0", ...

[ajnelson-nist]

I'd suggested over in #142, here, trying to adopt the XSD datatype hierarchy, to take advantage of the XSD "derive" notion and get hierarchy onto datatypes in SHACL.
But, I think that is a bit grander scope than this Issue (#309).

I think #309 is another member of the cluster of Issues #142, #160, #180 , and maybe others, which all clump around a centroid-notion about same-enough-except-for-typing literals.

I'd prefer #309 narrow in on datatype recasting of literals for conversion from one graph vocabulary to another. If I have:
an application that speaks RDF vocab X that uses a datatype T,
my data's in RDF vocab Y with a datatype U derived from T (in the XSD "derived" sense),
and there's a wholly mechanical translation possible from Y to X,
can a node expression handle the datatype conversion, without resorting to SPARQL?

I think the short summary of what I'm looking for here is how SPARQL's STRDT and lexical value extraction would work as a node expression.

Also, I specifically don't want to go in the other direction on timestamps - xsd:dateTime to xsd:dateTimeStamp requires enough logic around handling time zones that I think that'd sit as a higher application-level concern, not a SPARQL-level or SHACL-level concern.

[afs]

In SPARQL there tests for RDF term kind (is*), accessors (LANG) and tests for components (hasLANG) and then constructors to make RDF term - STRLANG. https://www.w3.org/TR/sparql12-query/#func-rdfTerms

[bergos]

I would prefer explicitly changing the datatype. Then, one has more control over the logic and is more transparent.

There should be a node expression function with the same functionality as STRDT to cast values. However, we could also add smarter convert functions in the XSD namespace that apply some logic to the value. e.g., convert a double exponential format to a decimal. Also, xsd:dateTime could accept non-ISO 8601 formats.

I'm not sure how far we should go in adding this to the specification. The cast function is easy, but convert functions can get complicated. The latter part should probably kept to the implementation.

[robert-david]

@ajnelson-nist is this issue solved by having a sparql:strdt (and sparql:str) function as mentioned in #455?

[ajnelson-nist]

@ajnelson-nist is this issue solved by having a sparql:strdt (and sparql:str) function as mentioned in #455?

@robert-david Likely. If SHACL Rules have access to sparql: functions, then it seems I could convert this function chain:

STRDT(STR(?lDateTimeStamp), xsd:dateTime)

to this Node Expression:

[ sparql:strdt ( [ sparql:str x ] xsd:dateTime ) ]

I just got back into the office today after some time off, so could use a hand - what would x be in that Turtle conversion? I also haven't seen yet if the Rules doc is ready to try this use case out, but that's just me catching up on email.

[afs]

If SHACL Rules have access to sparql: functions

It does.