Thanks, Jon. These solutions make sense to me. Perhaps as the world has
moved more in the RDF direction the default to RDF is more logical than
the default to the web page. (That's obviously open to discussion!).
I've done some mock-ups for adding a direct link onto the web page,
following the FOAF document example, which simply adds "(RDF)" with a
link after the version statement.
I suspect that these two changes would resolve the main issues relating
to easily finding the ontology in RDF. And would fit DC into the
defaults used in software that opens ontologies.
kc
On 5/5/14, 9:10 AM, Jon Phipps wrote:
> 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
>
--
Karen Coyle
[log in to unmask] http://kcoyle.net
m: 1-510-435-8234
skype: kcoylenet
|