ideamache_user wrapper and changes to creative_act

[amwebb]

A new wrapper is needed for IdeaMache users. The wrapper should include a collection field for the user's maches. It might should extend author or another type. Careful consideration of the ontology is required.

Once the new wrapper is written, the type of the creator field in creative_act needs to be changed to this new IdeaMache user type.

The polymoprhic_scope and wrap properties should be removed from the creator meta-metadata field.

[quyin]

@amwebb

I worked on this but had some troubles with the current set up of dependencies between projects.

The basic problem is that, currently, built-in types cannot extend or have fields that use a non built-in type. Built-ins are defined in BSCore, and non built-ins are in BSGeneratedClasses which depends on BSCore. If we refer from BSCore to BSGeneratedClasses, that will result in a cyclic dependency.

The type idea_mache_user needs to be referred in creative_act, thus it needs to be built-in. idea_mache_user.maches will be of type curation, which means curation needs to be built-in. curation extends creative_work, thus creative_work needs to be built-in.

So, to make this happen, with the current structure, one way is to make idea_mache_user, curation, and creative_work built-in, which does not sound very appealing to me.

Another way will be to make creative_act and rich_artifact non built-in, which looks better to me. But this will change how the type scopes for creative actions and rich artifacts are initialized -- the initialization needs to be moved to the application instead of inside MetaMetadataRepositoryInit, since those classes will not be visible from MetaMetadataRepositoryInit. This can possibly done by some helper function though, which takes in a root class and returns an expanded type scope.

What do you think?

[andru1d]

Why were they built in in the first place?

On Friday, October 10, 2014, Yin Qu (屈垠) notifications@github.com wrote:

@amwebb https://github.com/amwebb

I worked on this but had some troubles with the current set up of
dependencies between projects.

The basic problem is that, currently, built-in types cannot extend or have
fields that use a non built-in type. Built-ins are defined in BSCore, and
non built-ins are in BSGeneratedClasses which depends on BSCore. If we
refer from BSCore to BSGeneratedClasses, that will result in a cyclic
dependency.

The type idea_mache_user needs to be referred in creative_act, thus it
needs to be built-in. idea_mache_user.maches will be of type curation,
which means curation needs to be built-in. curation extends creative_work,
thus creative_work needs to be built-in.

So, to make this happen, with the current structure, one way is to make
idea_mache_user, curation, and creative_work built-in, which does not sound
very appealing to me.

Another way will be to make creative_act and rich_artifact non built-in,
which looks better to me. But this will change how the type scopes for
creative actions and rich artifacts are initialized -- the initialization
needs to be moved to the application instead of inside
MetaMetadataRepositoryInit, since those classes will not be visible from
MetaMetadataRepositoryInit. This can possibly done by some helper function
though, which takes in a root class and returns an expanded type scope.

What do you think?

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.

[amwebb]

i agree it would be better if they are not built-ins, but it's not going to
be that clean.

they are built-ins due to issues with generics and co-variance and the need
to define interfaces. those interfaces are manually created. as long as
they don't get overwritten or erased, we could put them in the generated
project. also, creative_act has an enumeration for the actions. that would
also have to be integrated into a generated creative_act class in some way.

On Fri, Oct 10, 2014 at 4:39 PM, Andruid Kerne notifications@github.com
wrote:

Why were they built in in the first place?

On Friday, October 10, 2014, Yin Qu (屈垠) notifications@github.com
wrote:

@amwebb https://github.com/amwebb

I worked on this but had some troubles with the current set up of
dependencies between projects.

The basic problem is that, currently, built-in types cannot extend or
have
fields that use a non built-in type. Built-ins are defined in BSCore,
and
non built-ins are in BSGeneratedClasses which depends on BSCore. If we
refer from BSCore to BSGeneratedClasses, that will result in a cyclic
dependency.

The type idea_mache_user needs to be referred in creative_act, thus it
needs to be built-in. idea_mache_user.maches will be of type curation,
which means curation needs to be built-in. curation extends
creative_work,
thus creative_work needs to be built-in.

So, to make this happen, with the current structure, one way is to make
idea_mache_user, curation, and creative_work built-in, which does not
sound
very appealing to me.

Another way will be to make creative_act and rich_artifact non built-in,
which looks better to me. But this will change how the type scopes for
creative actions and rich artifacts are initialized -- the
initialization
needs to be moved to the application instead of inside
MetaMetadataRepositoryInit, since those classes will not be visible from
MetaMetadataRepositoryInit. This can possibly done by some helper
function
though, which takes in a root class and returns an expanded type scope.

What do you think?

—
Reply to this email directly or view it on GitHub
<
https://github.com/ecologylab/BigSemanticsWrapperRepository/issues/39#issuecomment-58716092>

.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

[quyin]

The recent commits to BSJava, BSCSharp, BSWrapperRepo should have completed this request.

There are no ways of moving those types out of built-ins, otherwise we'll have to move some fundamental types, such as image and rich_document, out of built-ins. Since creative actions, products, and persons are central to our representation of many semantics, it seems OK to have authors, creative_work, and curation as built-ins, which is the current status.

[andru1d]

I guess ok for now, but it seems very kludgy.

Andruid

On Friday, October 10, 2014, Yin Qu (屈垠) notifications@github.com wrote:

Closed #39
#39.

—
Reply to this email directly or view it on GitHub
#39 (comment)
.

andruid kerne, ph.d.
director, interface ecology lab
associate professor, department of computer science and engineering
texas a&m university 979.862.3684 fax
college station, tx 77843-3112 http://ecologylab.net

http://facebook.com/ecologylab

Interfaces are the multidimensional border zones through which the
interdependent relationships of people, activities, codes, components,
and systems are constituted. Interface ecology investigates the
dynamic interactions of media, cultures, and disciplines that
flow through interfaces.