Change RDF type xsd:edtf

[JeroenDeDauw]

Quoting @andrawaag:

In the current implementation, edtf is stated as xsd:edtf, which is incorrect. EDTF is not part of XSD. Can this be changed to the applicable namespace? e.g. (https://id.loc.gov/datatypes/edtf.html)

[JeroenDeDauw]

What exactly is the expected output?

Right now we have

s:Q1-062ee677-4aeb-6ba3-b4d7-83b70e2db923 a wikibase:Statement,
		wikibase:BestRank ;
	wikibase:rank wikibase:NormalRank ;
	ps:P1 "2006-21/2006-24"^^xsd:edtf .

Should that become

s:Q1-062ee677-4aeb-6ba3-b4d7-83b70e2db923 a wikibase:Statement,
		wikibase:BestRank ;
	wikibase:rank wikibase:NormalRank ;
	ps:P1 "2006-21/2006-24"^^https://id.loc.gov/datatypes/edtf.html .

?

[mzeinstra]

@andrawaag Please check this.

Additionally it is importantt that the value shows up on the SPARQL endpoint. Currently that does not happen. I don't know if that is because of the unknown type (xsd:edtf) or some other reason. Can we try xsd:string as well to check whether the full edtf-date shows up on the sparql endpoint?

[andrawaag]

I would not include the HTML in https://id.loc.gov/datatypes/edtf.html. This might disrupt the content negotiation that is happening in Wikibase. I looked for a proper EDTF datatype IRI, but information on this is sparse. I ended up stumbling upon a ruby library that generated EDTF RDF and in the source code, I found the following IRI.

http://id.loc.gov/datatypes/edtf/EDTF

The prefix version could read as follows

edtf:EDTF
so the example mentioned above could read as:

 s:Q1-062ee677-4aeb-6ba3-b4d7-83b70e2db923 a wikibase:Statement,
		wikibase:BestRank ;
	wikibase:rank wikibase:NormalRank ;
	ps:P1 "2006-21/2006-24"^^edtf:EDTF

[GreenReaper]

I ran into this today while updating my schema to account for an EDTF period, using it with the simple SHEX validator (and the "query for all instances of ConFuzzled" in the schema comments).

✗wfd:Q4@!START
validating https://furry.wikibase.cloud/entity/Q4 as //furry.wikibase.cloud/wiki/Special:EntitySchemaText/Convention:
    validating "2019-05-24/2019-05-28"^^http://www.w3.org/2001/XMLSchema#edtf:
      Error validating "2019-05-24/2019-05-28"^^http://www.w3.org/2001/XMLSchema#edtf as {"type":"NodeConstraint","datatype":"http://id.loc.gov/datatypes/edtf/EDTF"}: mismatched datatype: http://www.w3.org/2001/XMLSchema#edtf !== http://id.loc.gov/datatypes/edtf/EDTF

The schema in question has period defined as wfdt:P16 edtf:EDTF ?, using PREFIX edtf: <http://id.loc.gov/datatypes/edtf/>. Of course I can change it to xsd:edtf but as noted above that doesn't actually exist, so we shouldn't use it - it could cause problems with tools that actually use the type, or generate items using it.

The item that failed has an EDTF period with start and end qualifiers that are EDTF points of time.

[mzeinstra]

@GreenReaper thanks for pointing our attention to this. Do you have a recommendation on how to solve this open issue? Using https://www.iso.org/standard/70908.html as the domain would also not work.

[GreenReaper]

Well, as @andrawaag suggests above, I think it should resolve to http://id.loc.gov/datatypes/edtf/EDTF. Probably by having @prefix edtf: <http://id.loc.gov/datatypes/edtf/> . emitted at the start of the entity data and then just edtf:EDTF instead of xsd:edtf, which will be more compact if there are several EDTF values.

I am not sure if there will be any problems within Wikibase with existing values of this type or if just changing it where the RDF is generated will work transparently.

It seems likely that anything that relies on the RDF output (e.g. WDQS) and stores it locally will require reindexing of entries using EDTF in order to pick up the change.

[mzeinstra]

Yeah, the issue we had with doing that is id.loc.gov is not the standard holder, but the only open explainer of the standard.

Feel free to create a pull request though, if you can see where to change this.

[GreenReaper]

Well, I can see the first place to change is

WikibaseEdtf/src/Services/RdfBuilder.php

Line 32 in 361831d

->value( $edtfSnak->getDataValue()->getValue(), 'xsd', 'edtf' );

. Perhaps also onExtensionRegistration to add the prefix, if it is not too soon? Or maybe it should go into one or both of the handlers below that? The readme also mentions xsd:edtf in a few places.

I don't know what to call to add the prefix but I'd be surprised if there was not a method. (Surely some other extension adds types not defined under one of the existing prefixes?)

Regarding the concern about it not being the standard holder, that is understandable; however if they have not arranged a URI, I think it is better to use something that exists than declare that it is part of XSD when it is not.

[mzeinstra]

I agree that it is better to not have it part of XSD, will you make the pull request, than we can discuss the proposal further there.