W3C home > Mailing lists > Public > public-lod@w3.org > February 2012

Re: using baseuri of a Dataset as the resource representing the Dataset itself

From: Sarven Capadisli <info@csarven.ca>
Date: Tue, 07 Feb 2012 19:18:51 +0000
Message-ID: <4F31791B.6050203@csarven.ca>
To: Armando Stellato <stellato@info.uniroma2.it>
CC: LOD Mailing List <public-lod@w3.org>
On 12-02-07 06:50 PM, Armando Stellato wrote:
> Dear all,
>
> a simple question about publishing datasets according to the VOID
> specification:
>
> I've a SKOS concept scheme (in the specific: AGROVOC:
> http://aims.fao.org/aos/agrovoc/) to publish according to the VOID
> specification. One very simple thing which came to my mind was: why not
> using the baseURI (again: http://aims.fao.org/aos/agrovoc/) of the
> scheme as a resource and publish it as a DataSet?, much like the common
> practice in ontologies is to use the baseuri as the resource identifying
> the ontology itself. This way, I would not use any file, and I would
> just make the data accessible through the SPARQL endpoint. The baseuri
> would also return - through HTTP access, in case of a request for any of
> the RDF mime-types - exactly the description of the Dataset.
>
> This is compliant with many access modalities suggested in the void
> guide (e.g. discovery of dataset through SPARQL queries would still find
> the dataset declaration).
>
> However, I did not find any example like this in the DERI guide nor in
> the W3C draft, so was wondering if there is any reason for rejecting
> this possibility.
>
> Best,
>
> Armando Stellato
>


Hi Armando,

The DataGovIE's VoID [1] describes the graph names for the vocabularies 
that are used in the datasets with the SPARQL Service Description.

If your SPARQL service is able to dereference remote graph IRIs (using 
FROM/FROM NAMED), you could get them on the fly. However, that's not an 
ideal solution. A local copy of the vocabulary is more preferable in my 
opinion.

[1] http://data-gov.ie/void.ttl

-Sarven
Received on Tuesday, 7 February 2012 19:22:03 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 31 March 2013 14:24:37 UTC