- From: Phil Archer <phila@w3.org>
- Date: Thu, 11 Oct 2012 13:04:15 +0100
- To: Richard Cyganiak <richard@cyganiak.de>
- CC: Government Linked Data Working Group <public-gld-wg@w3.org>
Following the WG's resolution last week [1] and the closure of this issue, the RADion namespace document has been installed at http://www.w3.org/ns/radion. The status section of that document makes it clear that it is not a W3C Working Group product. It actually defines very few things in its own namespace: :Repository :Asset :Distribution :distribution :distributionOf :keyword :version :versionNotes In terms of DCAT this means adding in 3 sub class relationships: dcat:catalog rdfs:subClassOf radion:Repository . dcat:Dataset rdfs:subClassOf radion:Asset . dcat:Distribution rdfs:subClassOf radion:Distribution . And 2 properties: dcat:distribution rdfs:subPropertyOf radion:distribution . dcat:keyword rdfs:subPropertyOf radion:keyword . Phil. [1] See just above http://www.w3.org/2011/gld/meeting/2012-10-04#The_larger_ISA_programme On 27/09/2012 17:38, Richard Cyganiak wrote: > Phil, > > I believe: > > 1. W3C people can publish stuff in www.w3.org/ns/ without needing permission from a WG > > 2. The WG doesn't need to do anything about RADion to fulfil its charter > > 3. Nevertheless, some find RADion useful > > 4. Adding mappings to RADion to the DCAT and ADMS RDFS files does no harm > > So I think the easiest way forward is: > > PROPOSAL: The WG resolves that RADion is *not* a GLD-WG product. If the RADion editor makes a credible assertion that he is going to publish the RADion namespace document regardless through some other venue (SWIG, community group, Just Ask the Webmaster, …), then GLD-WG will include mappings to RADion in the DCAT and ADMS RDFS files. > > Best, > Richard > > > On 27 Sep 2012, at 13:15, Government Linked Data Working Group Issue Tracker wrote: > >> ISSUE-36 (Kill Radion?): Should RADion be killed off? [DCAT] >> >> http://www.w3.org/2011/gld/track/issues/36 >> >> Raised by: Phil Archer >> On product: DCAT >> >> Richard and I have been discussing RADion in a bi-lateral thread and we need to bring it to the group for a decision between two, possibly three, options. >> >> Option A: Kill off RADion altogether and deal with the consequences for ADMS and those who have already implemented it (and perhaps incur not insubstantial displeasure from the European Commission); >> >> Option B: Keep RADion purely as a namespace document and refer to it more or less as planned; >> >> Option C: Hmmm, not sure. >> >> History and rationale: >> >> I proposed RADion (Repository, Asset, Distribution) when I was working on a vocab for describing software forges (not one that has made its way to GLD). The software forge vocab had a lot in common with DCAT and ADMS, in particular the structure of a catalogue that contains a bunch of conceptual items that may then have a number of distributions. It seemed to me that DCAT, ADMS and the software forge vocab are specialisations of a more general idea. >> >> The idea was always to use it purely as a reference point for sub classes, not as a vocabulary in its own right, so we'd have: >> >> dcat:Catalog rdfs:subClassOf radion:Repository . >> adms:SemanticAssetRepository rdfs:subClassOf radion:Repository . >> >> dcat:Dataset rdfs:subClassOf radion:Asset . >> adms:SemanticAsset rdfs:subClassOf radion:Asset . >> >> dcat:Distribution rdfs:subClassOf radion:Distribution . >> adms:SemanticDistribution rdfs:subClassOf radion:Distribution . >> >> Given DCAT's existing wide usage base, we should do the same for properties like: >> >> dcat:distribution rdfs:subPropertyOf radion:distribution . >> >> The individual vocabularies would be unaffected except for making those sub class/property assertions. The ADMS schema that I'm about to update includes these assertions and uses some properties directly. If we keep RADion, DCAT should make similar sub class assertions but in other ways be wholly unaffected. >> >> If this is useful in terms of modelling, then I'd suggest we keep RADion, publish it purely as a namespace document (not Rec Track) and make the relevant subclass relationships in ADMS and DCAT. It would take a bit of editing of teh existing namespace draft (http://philarcher.org/isa/radion_v1.1.html), review by the WG which could be done by e-mail, a short discussion in a call and the job would be done. Again, this is not a Rec Track doc - the burden on the group is not huge. >> >> Killing it off means: >> >> - no visible relationship between two vocabularies that have a great deal in common being published by the same WG; >> - removing all references to RADion in ADMS (remember ADMS has implementations already, hence people screaming for the RADion schema to be put in place); >> - replacing the RADion properties used by ADMS directly (like radion:distribution) with dcat versions such as dcat:distribution. An example of the impact there is that it would mean adding a new range statement as it currently has a range of dcat:Distribution - is having two ranges for a property a good thing?; >> - both ADMS and DCAT ignoring each other and minting new terms that look very similar, like adms:distribution. >> >> RADion is not a big vocabulary. It defines: >> 3 classes (Repository, Asset, Distribution) >> 1 pair of inverse object type properties (distribution and distributionOf) >> 3 datatype properties: keyword, version and versionNotes >> >> Everything else is Dublin Core and the like - which is what DCAT and ADMS use wherever possible of course. >> >> >> >> >> >> >> >> >> > > > -- Phil Archer W3C eGovernment http://www.w3.org/egov/ http://philarcher.org +44 (0)7887 767755 @philarcher1
Received on Thursday, 11 October 2012 12:05:07 UTC