Re: RADion - in name(space) only

Dave,

Sorry it's taken me a week :-( to reply to this. So much going on...

This morning I have to get a load of things related to the ISA Programme 
outputs ready for sign off by their working groups before they move to 
GLD. Preparing a publishable version of RADion is one such item and so 
your comments are very helpful, thank you.

Comments inline below.

On 15/03/2012 17:30, Dave Reynolds wrote:
[..]

>> 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.

OK thanks, see my conclusions below.

>
>> 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 :)

Review by the group is good and v welcome if available.

>
> 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:

Place, yes. Time, maybe not but let me answer your points as best I can.

>
> 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).

The Record class has been taken out. ADMS doesn't need it. I'm 
proceeding on the general rule that something must be identical or 
recognisable as doing the same job in all three of DCAT and ADMS and the 
OSS one to be included in RADion.  That makes RADion simple and, I hope, 
reduces contention to a minimum.

So, the Record class has gone. DCAT has it, I thought I heard a call for 
ADMS to include it but no, so it's gone. What has come in instead are a 
few terms that allow for metadata about an Asset provided by a different 
publisher to the actual Asset (so it's similar to DCAT's Record but not 
identical). After I've sent this I want to go back over that discussion, 
I'm not sure those new properties belong in RADion so they may not 
survive the next half hour as it all look a bit last minute and hasty 
which looks like a reason to exclude it for now at least. "If in doubt, 
take it out" seems a good axiom.

>
> 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.]

Any concern is legitimate. This looks like something we may want to add 
in/think about if this becomes a GLD item. It's beyond what we're doing 
in the ISA Programme - or rather, what we can do before our deadlines - 
but that's the advantage of discussing it properly in GLD if that's what 
happens.

>
> 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!

I have made this point ;-) Yes, it's just the conceptual model. For the 
RDF implementation of course id is the URI. But, bear in mind that these 
ISA Programme vocabs are also to be serialised in XML.

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

We've removed mention of SKOS as there is no other vocab mentioned. Even 
so, you don't think it's worth including inverse properties like that?

>
> 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").

Reification? Interesting, OK, but again, forgive me, time scales and 
limited scope of ISA Programme mean this would need to be taken up by GLD.

The 'version 0.01 of RADion will be online later today or Monday so the 
GLD WG will have a URI to point to and decide upon

Cheers

Phil.



Phil Archer
W3C eGovernment
http://www.w3.org/egov/

http://philarcher.org
+44 (0)7887 767755
@philarcher1

Received on Friday, 23 March 2012 10:14:37 UTC