ruby-rdf / rdf-vocab

Common RDF Vocabularies
The Unlicense
50 stars 29 forks source link

Dublin Core terms missing rdfs:subPropertyOf — propagates to RDF::Vocab #67

Closed doriantaylor closed 3 years ago

doriantaylor commented 3 years ago

DCMI has stripped rdfs:subPropertyOf from all their properties, and this has apparently been propagated to RDF::Vocab, as a bunch of inferencing I was depending on just broke. Compare the current spec with the previous one (which has to be obtained from wayback).

Do we do them (us) a favour and add these relations back?

gkellogg commented 3 years ago

Not sure why they would have stripped these triples, but RDF::Vocab should typically represent what's published, although in some cases, we've needed to maintain a separate vocabulary. I'd rather not do that for such a core vocabulary, though. It's probably worth questioning people at DCMI on why this was changed. For example, Tom Baker and Paul Paul Walk. Or, take it up as in issue in https://github.com/dcmi/repository.

cc/ @paulwalk, @tombaker

doriantaylor commented 3 years ago

I am going to assume it's a mistake since it isn't in the changelog but it's still in the prose. Moreover the lone owl:equivalentProperty is still intact. Is that repository the appropriate place to file an issue with them? Not a lot of activity on it.

gkellogg commented 3 years ago

If you like, I can roll back the update for this particular vocabulary until the matter has been resolved.

paulwalk commented 3 years ago

Many thanks for reporting this issue. In fact, you have, in passing, reported another issue, so I will treat these in turn:

1. Missing rdfs:subPropertyOf property

This was a simple mistake. We developed a completely new process to generate the RDF last year, and this property got missed. We have fixed the software to add rdfs:subPropertyOf where appropriate to the RDF, re-run the process, and checked the output. Because this is a non-breaking change, we have immediately re-built the website to incorporate this change (this is now 'live').

2. Having to go to the Internet Archive for previous specs

This was also a mistake, based on some legacy redirect instructions in the web server configuration. These redirects are no longer necessary, and so I have simply removed them. You should now be able to go directly to previous versions of the RDF.

Apologies for the inconvenience, and thanks again for reporting.

Paul & Tom.

(and no, we haven't gone entirely mad yet....) ;-)

tombaker commented 3 years ago

I just wanted to add that the current spec to which @doriantaylor pointed above - the HTML document - already correctly documented sub-property relations so did not need to be corrected. The previous version of that HTML document, along with all other previous versions (back to 2002) are available from a Release History page.

doriantaylor commented 3 years ago

Thanks; I was looking for a channel at DCMI (like a mailing list or something) to discuss this issue but didn't have luck finding one, so opened this issue in the interim while I continued to rummage around. I should note as well that http://purl.org/dc/terms/ will still not open in Protégé—presumably a problem with content negotiation?

paulwalk commented 3 years ago

I have just tested the conneg using Curl - e.g.

curl -L --header accept:application/turtle http://purl.org/dc/terms/

This is working as expected. Without an explicit 'header accept' then http://purl.org/dc/terms/ will deliver HTML by default (by design).

I'm not able to test with Protégé I'm afraid....

Regarding channels to raise issues - there's always contact@dublincore.net which we monitor.

gkellogg commented 3 years ago

Thanks @paulwalk, but note that the proper mime-type for Turtle is text/turtle, not application/turtle. In any case, I don't see any triples in the returned Turtle which contain rdfs:subPropertyOf. For example, the definition for dateAccepted:

dcterms:dateAccepted
    dcterms:description "Recommended practice is to describe the date, date/time, or period of time as recommended for the property Date, of which this is a subproperty.  Examples of resources to which a date of acceptance may be relevant are a thesis (accepted by a university department) or an article (accepted by a journal)."@en ;
    dcterms:issued "2002-07-13"^^<http://www.w3.org/2001/XMLSchema#date> ;
    a rdf:Property ;
    rdfs:comment "Date of acceptance of the resource."@en ;
    rdfs:isDefinedBy <http://purl.org/dc/terms/> ;
    rdfs:label "Date Accepted"@en ;
    rdfs:range rdfs:Literal .

The comment indicates it's a sub property of Date, but there is no such triple. But, the HTML documentation says it's a sub property of dce:date as well as dcterms:date.

curl -L -I -H accept:application/turtle http://purl.org/dc/terms/ indicates it's coming from http://dublincore.org/specifications/dublin-core/dcmi-terms/dublin_core_terms.ttl

The RDF/XML retrieved via content negotiation also doesn't include the property.

I'm happy to take this to the mailing list, if you like.

doriantaylor commented 3 years ago

Likewise; looks like my trouble with Protégé is mainly with Protégé itself, although http://purl.org/ontology/bibo/ (which redirects to https://www.dublincore.org/specifications/bibo/bibo/bibo.rdf.xml) is also acting up with a 403, but only in Protégé.

Is something different in the way dublincore.org handles conneg?

paulwalk commented 3 years ago

I will have to pick this up in the morning - but just to say I'm more than happy to sort it out here in GitHub.

paulwalk commented 3 years ago

I believe this should be OK now.

I have tested curl -L --header accept:text/turtle http://purl.org/dc/terms/ and can see some rdfs:subPropertyOf properties in there.

Sorry about this - there were two issues:

  1. I forgot to generate the Turtle and RDF-XML from the NTriples which are generated by my script
  2. It was all cached by Cloudflare anyway....

I have purged the caches -should be OK now.

gkellogg commented 3 years ago

Thanks, Paul; I see them there now.

@doriantaylor I'll update and create a new release.

doriantaylor commented 3 years ago

Thanks!