RE: [Moderator Action] Re: Approach to USDL variant management

Hi Jan,
thanks for the feedback. Some replies from me below

> The following comments and questions come to my mind, when thinking
> about a possible move from ECore to CCTS. They are meant for a global
> USDL-only variant repository, not repositories for other types of
> objects. In general a central repository for all USDL variants sounds
> like a good idea to me.
The repository should contain USDL variants in the first place.

> technical
> - are all concepts of ECore based USDL representable in CCTS?
>    - will they always be for all variants?
Probably not. This is something to be analyzed

>    - is the basic vocabulary extensible?
Yes

> - context categories
>    - might require more than a flat list or lots of categories
>    - compound categories might be required to limit the set of
>      described entities
Currently not possible and not planned AFAIK

>    - as an example consider a B2C or B2B over legislative
>      borders, e.g. a German consumer buying a U.S. service.
>      Both laws might apply for parts, which would require
>      a country-by-role context category. (this is not handled
>      by USDL at the moment)
> - could CCTS unify variants, where one specifies two separate
>    "fields" while the other uses a composite field?
Not possible AFAIK

> process/organizational
> - finding a mediating/governing actor could be problematic
>    regarding effort and fairness for all participants
As mentioned before we will present the solution to W3C. 
One might think of W3C being such an independent organization.

> - how is market dominance weighed in a mediation considering
>    possibly uncooperative entity creators?
> - how to avoid the occurrence of multiple repositories with
>    separate mediators?
> 
> semantics
> - is CCTS providing an aspect of semantics for each entity?
What do you mean by "semantics" (the neverending terminology problem ;-)?

> - is there a notion of "similarity, but not identity"
>    between entities?
Don't think so

> How about extending the ECore representation to handle variants? The
> central repository would deliver ECore schemata depending on given
> input. Tooling still would be available with the requirement to be
> able to handle all variants or tooling would require a variant
> management too.
Yes, that is something we should consider.
It seems a frequent demand not to lose the software engineering support from EMF/Ecore

> As a final note: I am not involved in the LOD community, but how well
> does the CCTS "central schema consolidation" coexist with the openness?
You probably have to look at it on two levels:
1) representation level: I see the CCTS representation and LOD representation as two possible concrete syntaxes of USDL
2) governance level: the approach for variant mgmt (incl. CCTS for representation and common vocabulary) gives tool support for governance processes. The LOD approach for governance is implicit (grass-roots, community-based). The two worlds probably clash here ...

Best
 Daniel

Received on Thursday, 31 March 2011 09:25:54 UTC