Re: ISSUE-37 (nonLiterals): How should dcat publishers figure out good URIs for properties with non-literal ranges? [dcat]

Hi Ed,

On 27 May 2010, at 15:41, eGovernment Interest Group Issue Tracker  
wrote:
> http://www.w3.org/egov/IG/track/issues/37
>
> Raised by Ed Summers:
> http://lists.w3.org/Archives/Public/public-egov-ig/2010May/0056.html
>
> I wonder if it is worthwhile acknowledging (at least to ourselves)  
> that the ranges of dct:publisher, dct:accrualPeriodicity,  
> dct:spatial, dct:temporal, dcat:granularity, dcat:theme could be at  
> odds with the
> Simple Transformation From Existing Catalog Data requirement.  For  
> example a dataset publisher may know that the dataset is about  
> "Berlin, Germany" ... but they would have some work to do to figure
> out what URI to use with dct:spatial. Similarly they may know that a  
> dataset is published by the National Aeronautics and Space  
> Administration, but they will have to do some work to use a  
> linkeddata friendly URI like <http://dbpedia.org/resource/NASA>.

You are right, this is a question that needs addressing: For  
properties where the value is not a literal but another resource, how  
does the catalog publisher turn the string values in their database  
into RDF resources?

There might be three possible answers, or combinations thereof:

1. Just translate the strings to blank notes with rdfs:labels. This is  
simple and can always be done, but isn't very helpful from a linked  
data point of view (blank nodes cannot be linked to anything else)

2. Translate the strings to a controlled set of URIs (e.g., "Berlin,  
Germany" => http://mycatalog/spatial/Berlin,%20Germany). Like option  
1, this can be done automatically, but there are some complications  
around actually making these URIs resolvable (e.g., think of a website  
with embedded RDFa), . Big advantage of having a URI over a blank  
node: You can link to established identifiers after the fact using  
sameAs.

3. Map the strings to well-known identifiers from existing datasets,  
e.g., http://dbpedia.org/resource/Berlin. This probably has to be done  
manually, so is at odds with the “Simple Transformation From Existing  
Catalog Data” requirement. But it would produce the highest-quality RDF.

Are there any other options that I'm missing? Should we just document  
them all? Does any of the options hit a sweet spot?

Best,
Richard

Received on Thursday, 10 June 2010 14:56:23 UTC