fdp-specs / fdp-specs.github.io Goto Github PK

The specs use http://purl.org/fdp/fdp-o# as the fdp-o prefix, but the home.fairdatapoint.org harvester refuses to accept this. The FDP is marked as invalid. This could be fixed by replacing the purl.org prefix with https://w3id.org/fdp/fdp-o#. Both locations refer to the same OWL file on the same GitHub repo but in different tags (master vs. v1.1, respectively).
This may highlight a problem in the specs, a problem in the harvester, or an issue with the logic of redirecting URIs used as identifiers. In the latter case, my logic argues that if two URIs point to the same object, the two URIs should be considered aliases of the same object and, therefore, should be usable interchangeably.

What type(s) of issue is this?

Ambiguity, Other (specify in text)

What is the issue?

<https://w3id.org/fdp/fdp-o#metadataIssued> a owl:DatatypeProperty ;
        rdfs:subPropertyOf <http://purl.org/dc/terms/date> ;
        rdfs:domain <https://w3id.org/fdp/fdp-o#Metadata> ;
        rdfs:range <http://www.w3.org/2001/XMLSchema#dateTime> .

Should at least be more specific to be the subproperty of dcterms:issued. But it really raises the question should these properties exist at all?

@ericprud

Example 1, line five, should be terminated with a ;
Tried a few validators and they all crash on that line, adding a ; to the end of line 5 makes it validate properly.

What type(s) of issue is this?

Inconsistency

What is the issue?

In the file [https://raw.githubusercontent.com/FAIRDataTeam/FDP-O/v1.1/fdp-ontology.owl] we see

  <!-- https://github.com/luizbonino -->

    <owl:NamedIndividual rdf:about="https://github.com/luizbonino">
        <rdfs:label rdf:datatype="http://www.w3.org/2001/XMLSchema#string">Luiz Olavo Bonino da Silva Santos</rdfs:label>
    </owl:NamedIndividual>
    

but also

    <!-- https://w3id.org/fdp/fdp-o#Metadata -->

    <owl:Class rdf:about="https://w3id.org/fdp/fdp-o#Metadata">
        <rdfs:subClassOf rdf:resource="http://purl.org/dc/dcmitype/Dataset"/>
        <dc:creator rdf:resource="http://orcid.org/0000-0002-1164-1351"/>
        <dc:date rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">2020-09-25T10:09:40Z</dc:date>
    </owl:Class>

The IRI [http://orcid.org/0000-0002-1164-1351] represent the same concept as [https://github.com/luizbonino] and the spec should chose one.

According to the specs, the FDP endpoint requires (amongst others) the following two properties:

However, the specs of the catalog mention the following four properties:

It seems to me that this is redundant? I've checked two example FDPs, and they do implement both the dct as well as the fdp properties for catalogs, even though the values are the same. Rajaram's example GitHub FDP only uses the fdp fields for the catalog. I'll skip the dct fields in my implementation as well, which is allowed according to the specs, but I thought I'd report this regardless.

The specs indicate that the use of fdp-o:conformsToFdpSpec is mandatory, but I have never found an FDP that actually uses it, besides my own implementation. Is it really mandatory, and is it a bug in the reference implementation and other implementations? Either way, it currently can't really be implemented properly because of #4.

The link in the specs that is supposed to link to the current version of the specs doesn't actually work.
Therefore, it's not possible to link to the used version of the specs in the fdp-o:conformsToFdpSpec property.

It's not clear from the specs how to use dct:conformsTo. It is supposed to link to a profile that contains the specification of the FAIR Data Point's metadata schema (in SHACL). However, I can't find the "official" FDP SHACL metadata schema online, and that is perhaps why I can't find a single FDP that has the dct:conformsTo implemented (at all, or correctly). My guess is that this is a specs issue, hence my bug report.

What type(s) of issue is this?

Other (specify in text)

What is the issue?

MIT is for Software, a specification should use a different license. Specifically for the published ones.