Jeff, thanks. It looks like this is the relevant part of the
recommendations in the w3c page:
---------------------------------------------
Step 1
Create a file called example1a.rdf that contains a complete RDF/XML
serialization of the vocabulary. I.e. all resources defined by the
vocabulary are described in this file.
Step 2
Copy example1a.rdf to the directory /apachedocumentroot/examples/ on the
server from which you wish to serve the content (in this example the
server is www.w3.org).
Step 3
Set up the following PURL:
PURL: http://purl.org/NET/SWD/recipes/examples-A/example1a
URL: http://www.w3.org/2006/07/SWD/recipes/examples/example1a.rdf
Notes
If the server is already configured to serve files with the .rdf
extension as content type application/rdf+xml then you don't have to do
anything further.
___________________________________________
This appears to require that the DC RDF file be the URL for the PURL:
http://purl.org/dc/dcterms/
Is that how you understand it?
kc
On 5/4/14, 1:27 PM, Young,Jeff (OR) wrote:
> Here's a Linked Data validator report on the namespace and one of the terms:
>
> http://validator.linkeddata.org/vapour?uri=http%3A%2F%2Fpurl.org%2Fdc%2Fterms%2F
> http://validator.linkeddata.org/vapour?uri=http%3A%2F%2Fpurl.org%2Fdc%2Fterms%2Ftitle
>
> It looks like content negotiation is working on both, but some tools are fussy about the initial 303, which could be a stumbling block. The issue is mentioned here:
>
> http://www.w3.org/TR/swbp-vocab-pub/#purls
>
>> On May 4, 2014, at 3:26 PM, "Karen Coyle" <[log in to unmask]> wrote:
>>
>> 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
|