motools / musicontology

The Music Ontology Specification provides main concepts and properties fo describing music (i.e. artists, albums, tracks, but also performances, arrangements, etc.) on the Semantic Web.
http://purl.org/ontology/mo/
121 stars 35 forks source link

`encoding` uri broken #13

Open CharlesHolbrow opened 6 years ago

CharlesHolbrow commented 6 years ago

The 'encoding' link seems to be be broken found at http://musicontology.com/specification/#term-encoding references http://purl.org/ontology/mo/encoding, which returns a broken 302 redirect.

$ curl -i http://purl.org/ontology/mo/encoding
HTTP/1.1 302 FOUND
Server: nginx/1.4.6 (Ubuntu)
Date: Tue, 28 Aug 2018 17:17:01 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 223
Connection: keep-alive
Location: http://pingthesemanticweb.com/ontology/mo/musicontology.rdfs
Access-Control-Allow-Origin: *

<!DOCTYPE HTML>
<html>
<head>
<title>302 Found</title>
</head>
<body>
<h1>Found</h1>
<p>The resource requested is available <a href="http://pingthesemanticweb.com/ontology/mo/musicontology.rdfs">here</a>.<p>
</body>
</html>

The 302 redirect points to the pingthesemanticweb.com domain, which appears to be a german bitcoin website. The /ontology/mo/musicontology.rdfs resource appears to be unavailable.

zazi commented 6 years ago

looks like that we need to fix the redirect config at purl.org. I guess the only ones who could probably do this are @fgiasson or @moustaki. Couldn't we simply redirect it to https://raw.githubusercontent.com/motools/musicontology/master/rdf/musicontology.rdfs ? (dunno, whether conneg is then broken, i.e., I doubt that conneg is supported at this part of github, or?)

CharlesHolbrow commented 6 years ago

I think there might be some other issues with the prul.org redirects. Correct me if I'm wrong, but a lot of .n3 files (those generated by sonic-annotator) include the following prefix.

@prefix mo: <http://purl.org/ontology/mo/> .

in the same document, a mo:AudioFile would then resolve to <http://purl.org/ontology/mo/AudioFile>, which HTTP redirects to an .html file (instead of a .n3, .rdf, or .owl).

Is this allowed by the spec? If I understand correctly, it means that all n3 files output by sonic annotator are broken. I'm not super familiar with now linked data, but this seemed weird to me.

 $ curl -IL http://purl.org/ontology/mo/AudioFile
HTTP/1.1 302 FOUND
Server: nginx/1.4.6 (Ubuntu)
Date: Wed, 29 Aug 2018 15:02:08 GMT
Content-Type: text/html; charset=utf-8
Content-Length: 203
Connection: keep-alive
Location: http://musicontology.com/terms/AudioFile
Access-Control-Allow-Origin: *

HTTP/1.1 303 See Other
Date: Wed, 29 Aug 2018 15:02:08 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
Location: http://musicontology.com/specification/#term-AudioFile
Content-Type: text/html; charset=iso-8859-1

HTTP/1.1 200 OK
Date: Wed, 29 Aug 2018 15:02:08 GMT
Server: Apache/2.4.6 (CentOS) PHP/5.4.16
Content-Location: index.html
Vary: negotiate,accept
TCN: choice
Last-Modified: Mon, 19 Feb 2018 15:57:33 GMT
ETag: "26479-56592c08a4fb3;ef-56592c08a4fb3"
Accept-Ranges: bytes
Content-Length: 156793
Content-Type: text/html; charset=UTF-8
zazi commented 6 years ago

@CharlesHolbrow : it's not the n3 output of sonic annotator which is broken, but the redirect configuration from the Music Ontology is somehow broken. Usually you can set an accept MIME type via the "Accept" HTTP header, e.g.,

curl -H "Accept:application/rdf+xml" -IL http://purl.org/ontology/mo/AudioFile

which should you direct you to the RDF/XML serialisation of the Music Ontology.