Hi Karen, When I was working with Tom setting up the PURL redirects a
few years ago, Tom felt that it was important for the PURL-based URL
redirects to default to the HTML page rather than RDF because 1) that
was consistent with people's historical expectations and 2) web sites
that linked to the PURL URIs expecting to retrieve HTML should not get
RDF. That's easily remedied by simply changing the _default_ (no header)
response of the DCMI web site. The direct link to the RDF file should
also be obvious in both the header of the dcterms html page (I opened an
issue related to this, amended by Greg Kellog, 2 years ago:
https://github.com/dublincore/website/issues/10 ) as well as made more
prominent on the page itself.
Jon
On 5 May 2014, at 10:56, Karen Coyle wrote:
> Thanks, Adrian. It's still mysterious to me that the base URI + a
> property directly returns the ontology, but the base URI does not, and
> requires -L -H to work. In other words, I find the results something
> less than predictable, meaning that we are putting the effort on our
> users (including programs), who need to figure out how to get to the
> DC ontology in a way that is different from other ontologies. That's
> not good. Trying to get the dc ontology shouldn't be something that
> could get turned into a competition to see who can figure it out :-).
>
> We still need 1) for this to work easily with software that imports
> ontologies using on a base URL and 2) for there to be a clickable link
> on the DC site to get the ontology. Other ontologies are available in
> this way, that DC is not is a problem. This is one of those cases
> where being different isn't good user service.
>
> So the question remains: How can we fix this? FOAF seems to have done
> something that works, but is that solution worksable with the PURL
> service?
>
> kc
>
> On 5/5/14, 12:28 AM, Adrian Pohl wrote:
>> Hello Karen,
>>
>> curl works for me to get the rdf. Besides following the redirects you
>> have to set the HTTP accept header to make content negotiation work,
>> e.g.:
>>
>> curl -L -H "Accept: text/turtle" http://purl.org/dc/terms/
>>
>> (The "-L" is an instruction to follow redirects and the "-H" sets the
>> Accept Header.)
>>
>> To get RDF/XML: curl -L -H "Accept: application/rdf+xml"
>> http://purl.org/dc/terms/
>>
>> You can get the different serializations even easier with rapper [1]
>> (which I normally use to get RDF vocabs:
>>
>> rapper -o turtle http://purl.org/dc/terms/
>>
>> All the best
>> Adrian
>>
>> [1] http://librdf.org/raptor/rapper.html
>>
>>>>> Karen Coyle <[log in to unmask]> 05/04/14 9:26 PM >>>
>> I ran into this problem when attempting to load dcterms into Protege.
>> [1]
>>
>> Using:
>>
>> http://purl.org/dc/terms/
>>
>> as an input URI to Protege failed. Following up using CURL, this led
>> me
>> to (shorted output):
>>
>> step 1) curl http://purl.org/dc/terms/
>> <TITLE>302 Found</TITLE>
>> The resource requested is available <A
>> HREF="http://dublincore.org/2012/06/14/dcterms#">here</A>.<P>
>>
>> step 2) curl http://dublincore.org/2012/06/14/dcterms#
>> <title>303 See Other</title>
>> <p>The answer to your request is located <a
>> href="HTTP://dublincore.org/documents/2012/06/14/dcmi-terms?v=terms">here</a>.</p>
>>
>> step 3) curl
>> HTTP://dublincore.org/documents/2012/06/14/dcmi-terms?v=terms
>> <title>301 Moved Permanently</title>
>> <p>The document has moved <a
>> href="http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=terms">here</a>.</p>
>>
>> This last URL pulls up the DC web page, NOT the ontology. Which means
>> that http://purl.org/dc/terms/ leads to the web page on the DCMI
>> site,
>> not the ontology.
>>
>> If instead I include a *property* in the request, e.g.
>> http://purl.org/dc/terms/title, then:
>> 1) Protege loads up the *entire* ontology (without a problem), not
>> just
>> the property requested
>> 2) the curl steps lead me after a single 303 to the
>> http://dublincore.org/2012/06/14/dcterms.rdf, which is the correct
>> RDF file.
>>
>> DCMI was presumably emulating the FOAF method of presenting the
>> ontology
>> as a web page with RDF behind it. But there is something different:
>> with
>> the FOAF general ontology URI: http://xmlns.com/foaf/spec/
>> 1) you get back the RDF with a curl request on that URI
>> 2) protege loads the FOAF ontology fine from that unqualified URL
>>
>> It turns out that FOAF has its RDF at
>> http://xmlns.com/foaf/spec/index.RDF. I don't know if this would work
>> with purl.org. It looks to me like dcterms doesn't have a landing
>> point
>> for the RDF that can be reached with the base URI.
>>
>> I started with the assumption the the namespace root for dcterms
>> would
>> do content negoation leading to the RDF ontology. It seems that
>> others
>> might assume that they could import dcterms to ontology software
>> using
>> the root URI. That you can do so by adding any of the properties is
>> not
>> intuitive.
>>
>> Has anyone here had this experience, and do you know of a solution
>> that
>> would work for dcterms? Has anyone tried this with software other
>> than
>> Protege and had success?
>>
>> Thanks,
>> kc
>> p.s.Thanks to Tom Baker for letting me fill his Skype chat with my
>> attempts, failures, and successes, on a Sunday!
>>
>> [1] http://protege.stanford.edu/
>>
>
> --
> Karen Coyle
> [log in to unmask] http://kcoyle.net
> m: 1-510-435-8234
> skype: kcoylenet
|