Re: RADion - in name(space) only

On 15/03/12 16:23, Phil Archer wrote:
> Thanks to everyone on today's call, especially Dave for scribing. I'm
> sorry you had to put up with so much of me talking.

n.p.

> Towards the end I heard Bernadette and others expressing entirely
> justified worries about mission creep and putting a cap on taking on
> more than we should. Against that, I believe that some sort of
> association between DCAT and ADMS is desirable, not to mention any other
> vocabularies that might come along to describe repositories (like the
> one I'm working on concerning software forges).

I think that was partly confusion between RADion and your OSS 
vocabulary. You had just pointed out we *could* consider taking on the 
OSS vocab as well, but you weren't expecting us to. I took Bernadette as 
referring to that. They were not necessarily ruling out RADion itself.

> Therefore, my proposal is that I publish RADion as little more than a
> namespace document at a suitable location on w3.org. The GLD WG can then
> decide whether or not to make relevant sub class relationships between
> RADion and DCAT in the way that ADMS will. I hope that DCAT will too but
> there will be no dependency created by this action.

I think it would be preferable to consider including RADion within the 
working group because then we get some say about what's in it :)

At first glance I have some concerns about RADion and the model it 
implies [*] so having a chance for the WG to review it would possibly be 
helpful.

Dave

[*] Not sure if this is the time/place to start the detailed discussion 
but my initial worries are:

1. It is not clear why a Repository should contain both Records and 
Assets. Should be one or the other but not both (and ideally Records).

2. There seems to be no notion of collection structure. In several 
registry standards you have the notion of a Registry (the service) which 
contains Registers (collections of registered items) which contains 
Assets. The Register is where governance regimes get applied. So for 
example Joinup (the registry) might say "here is the Register of 
standards approved by the EU for use in Environmental modelling". The 
point about a Register is that it is closed world and can't be modelled 
through tags or topic markers.

[I realize you are talking about Repositories rather than Registries but 
since on the call you said RADion was intended to be a foundation for 
Registry use as well this seemed like a legitimate concern to raise.]

3. The id fields. In a Linked Data world, of course, the entity is 
identified by URI it doesn't have a URI 'id' as its property.
Maybe this is just the way you are using UML but if you mean that an RDF 
vocabulary for this model you will have a property like "radion:id" then 
we have some talking to do!

4. Minor: pointing back from the SKOS:Concept to the assets marked with 
that topic ("theme of") doesn't necessary.

5. Minor: you might want to consider having a refied "Related Asset" 
relationship rather than a direct link. Makes it easier to add/discover 
new types of relationship and to allow extension to n-ary relationships 
without a discontinuity ("<this> asset was derived from <that> asset by 
<this process run by <this> agent").

Received on Thursday, 15 March 2012 17:30:45 UTC