Language changes and notes on current implementation - added domain directive - allow the description in Vocabulary section of terms in external ontologies - require all non-abstract data types to be explicitly bound to a rule set - defaultOrderBy moved to Descriptions section and added argument (changed in doc too) - RequiredMembers section and rm for SOC - Comments - krr rule identifiers must be lower case-- though we're not checking for this yet - comp vector functions are always executed under the language "none"--for now - typeInCode directive in RuleSet, for literals - "default" and other strings may be impossible to use as identifiers because they're seen by the parser as something else - multilingual text no longer allowed in Area, FullDesc and ShortDesc - (to be implemented) multilingual text no longer allowed in uniqueDF, and should be allowed in label and in uniqueTextBPV Language issues - need better names for single and multiple krr rules. - should useDefinition instead be includeDefinition or copyDefinition, to make it clear the reused definition can be refined with further struct requirements? - should rule set binding not be inherited over the data type hierarchy? Should multiple ruleset binding be allowed? Or should the ways to inherit stuff from one ruleset to another be improved/expanded? - inference rules that are global and view and assign a KRRelationRule that appears in multiple RuleSets? Or operate on any descriptor that uses a given property? Or will global inference rules have to define their own KRRelationRules? Relationship to useDefinition? - is a general renaming of stuff required? - possible inclusion of JavaDoc- / RDoc-like comments, and their relationship to the comment directive - may a given rule set be bound to the values of more than one data type? What would the point of that be? How would this interact with rule set inheritance? - move (some?) ordering directives to SOC section? - clarify purpose and functioning of abstraction from properties to descriptors: (1) descriptors' "added functionality" (ordering, lang specificity, null values); (2) descriptors' role in creating new structures and association with rules for that purpose; (3) the indexing of descriptors' in and out nodes for rapid traversal; or (4) descriptors' use as basic building blocks in longer path expressions. Pending this clarification the name "descriptor" could well be changed. - inheritance in RuleSets, or among rules themselves? Check out delegates in C#. This will complicate KR relations, allowing some quieres to spew lang-restricted and non-lang-restricted nodes. - sometimes we may need something like sublenses here... what about including descriptions in others, and allowing named descriptions (in addition to the standard ones)? - should multilingual, mult ordered, and perhaps even other structure rules, be transfered to Property in the Vocabulary section? That might simplify stuff global mult krrr... - required implementation and overriding of Comp Vector funcitons. Comp vectors may be set from any data type, and implementing functions are required for all non-abstract data types in the set of types that includes the type that sets the vector and all its descendants. - if a non-abstract data type is always bound inextricably to one and only one ruleset, why not put that ruleset right there with the definition of the data type? Hmmm.... - the definition of comp vectors directly with a data type and comp vector functions in the rulesets leads to the following situation: if a ruleset is used for several data types it may define comp vector function that implements different comp vectors with the same identifier, established by the data types bound to. - perhaps all code blocks should either have a language specified or be prepared to be executed under the Lang.NONE. Perhaps the embedded Ruby code should also be able to switch its environment from one lang to another. - verbosity of path expressions: shouldn't we not have to state rule set and all that jazz for a node that we know has such-and-such a relation rule attached? - what about embedding other little useful Ruby procedures into RuleSets, say, to covert from cm to mm and back... And... aren't we in some sense re-inventing oo programming? What's different? What makes it worth the effort? - a comp vector's return type is often defined far away from the related function - create theoretical background for KStatements (or whatever...) - rdf:type as a way of assigning a complex value a complex datatype is iffy because an object often is an instance of several types--at least by inference - Need to add extra info to MultipleKRRelations: equiavlence, extraInfo, for example. This info will be used both in creating intelligent search results and helping administrators enter data - No syntax available for making UniqueBPV multilinugal or not - UniqueTextBPV vs. label? UniqueTextBPV vs. UniqueTextBPVFunction? - It should be illegal to refer to textBPV's in KRRelationRule conditions, and probably in ComparisonVectorFunctions, too. - It would be a lot simpler to just link RuleSets to classes--most of the time. Can't we allow that option too? - Should textBPVFunctions and CompVectorFunctions be the same thing, or almost? Should we be able to define functions that can return any value, and simply say that defaultTextBPV and defaultImageBPV ones need to return what they need to return? - Flexibilize, make more configurable, the global model organization, to make the system more useful in other contexts? Check out NLR, for describing the roles of graphs (see ESWC2007 proceedings); see also that for tools for combining graphs - Parallel hierarchies of properties and base rules? Ouch! Properties have sub/super relationship, base rules don't... How to specify? How to keep it flexible but not spaghetti-ish? - "or" operations in path definitions of MultipleKRRelations - Determining which rules have results that are groupable or orderable is messy, since underlying properties may have many ranges-- and what about taking into account superproperties, too? - Diverse things are effectively assigned at collection level without being explicitly so, such as significance of a resource (= membership in a main-level soc) - Allow some data types to prohibit or require language tags? - Se necesita una etiqueta general de un campo (por ejemplo, para opciones de ordenado, agrupación o campos) pero el lenguaje permite a veces variar la etiqueta de maera distinta para cada objeto descriptible; entonces, ¿de dónde sacamos el nombre general? - Note distinction between the labels on a property (used to designate the property out-of-context) and the variable desc options (used to designate a rule in the context of a specific rule set). In groupings of search results, in describing paths, we'll be using the out-of-context info - Short descriptions should actually be a default configuration of variable description - Problem with name csv of files for complex values: what if different realms need values of the same type? Only one file for such values is available. - path rules need to be able to specify a generic reference to a rule, that is, one that includes the original rule and all "derived" (or inherited) ones - More flexibility in presenting BPV functions in templates needed - What if you want a field to show a specific TextBPVfunction, but be ordered by a CompVectorFunction? Or by a KRRR? - How to do something like: make all classes be able to say their name in singular and plural? A textBPV function with an argument? Or what about if other DO's want to do something similar? Other textBPV's with arguments? We're getting pretty plain-OOish here... - prop/class hierarchy in order/group options, for example misma serie/misma serie otra cámara - non-use in search of labels of unique df's in variable desc or elsewhere, that provide a context-free description of a field/path - in some backtrace paths, the need to omit parts thereof, and in others, the need to include the exact same partes; this should be studied with regard to blending - deal with default property ordering, when no explicit ordering mechanism is established; and also alternate automatic ordering mechanisms - at times a lable for a field may be different on a per-object basis (if we run code in UniqueDF), but then how shall we call that label globally (for example, in the list of fields available)? Or should we eliminate per-object flexibility? Or add another option for setting a "global" name? - Make setting and adhering to just one range obligatory for properties? Would that simplify decisions such as how to order stuff? (maybe not--considering that sometimes we'll show info on the basis of superproperties, and that's like having several ranges...) - Comparison vectors are at essence abstract methods. How can we generalize them in these terms? Will this be like adding abstract methods to Ruby? - A full-fledged IDE is really necessary. We two human-computer interfaces: Sofía/IDE (programmer's interface) and Web (user's and cataloger's interface). We can modify RDT. - For a new Ruby-based language, will Ruby's one-pass interpreting (which forces a certain order of declarations) be a problem? Can we modify this by modifying JRuby? Maybe try leaving this issue alone, and later reviewing it... Actually maybe this forces a certain orderliness of things that we might want... - if no relations are available for ordering lists of something, we should automatically take the URI - for comp vector functions, we're checking for specific return types. this goes against Ruby philosophy. If we're generalizing comp v functions to be just methods, should we abandong this, for consistency? - terminololgy: we have two classes called "group": one is in krview, the other in nodedgraphelements - NLP is where we'll be able to differentiate between a simple designation and a composite one, which is a boogeyman of our text BPV scheme - Allow special bits of business logic for search path creation? Such as for part-to-whole relationships, like places? Find patterns here? - In multilingual search/extraction fallback, the language priorities should change in the case of place names: for any given place name, if none is available in the user's language, then the original language may be used, though in the case of some alphabets, transliteration is necessary - Note subtle differences in how info from fields is presented: in order options/grouping opts, short record and full record; in particular, sopport measurements and place of photo - With new proposal for refering to elements of one rule-set from another by their local ID in that class, we introduce new inefficiencies for multi-node operations: for each node we'll need to look up the function again, because we won't be able to predict the node's class. This is basically a messaging issue. - Rule sets will eventually need private methods, variables, etc., in order to allow completely structured programming. Why didn't I think of this before? - In new version, be very coherent regarding where messages are taken, decoded--though all this will be done by jruby, no? - Model alternate names of places to achieve correct search results - Prototypical operations: one-from-many (many values for a given property, only one taken) and unity-from-diversity (a list of things of many classes/bound to many rulesets, with unified ordering and grouping options; a set of resources whose values for a property may be of different data types, or many not exist, processed uniformly) - idea for advanced search: show mock-up of a full record, with selection widgets to allow the user to indicate in which field to search - mechanism for "suggesting" similar fields in other record formats, for widening search and re-applying field view preferences - need for superclass of data types and concrete classes: for example, location on object may be a class that defines a category of place (frontside, lower) and a complex data type (pages 2 to 4) - here is some more noise: "value" appears both in our abstraction layer and as part of a df - the frequent dilema of whether to put a bit of logic or information with a property or with the thing that it has as a value merits general exploration - interesting modelling problem: inscribed title, which goes with an image as content, may change its way of being explained, depending on which physical object it's being shown with: if the title was inscribed on this object, "el objeto", or if on another object, "en otro objecto" (or something similar)--and what if it's on several objects? Points to the need for defining contexts for NLG - we need to model the reasons for saying certain things: especially the dates of photos, for example - with regard to inscribed title, consider also the need for defining a path from the reference to the inscription, taking into account the hierarchy of components and larger objects, and the need for a functional, friendly nl mention of the object the inscription is on - consider the issue presented by the phrase, "Tinta verde, con escudo nacional de la época", refering to a seal; tinta verde refers to a characteristic of the manifestation, and the rest are the words that are imprinted on the physical seal itself; it's difficult to generate this short, concise phrase from the model itself--we'd need quite advanced nlg, with special configurability all the way down to the level of cataloger-defined elements (unless we separate the phrase in two, divided by a slash or something of the like); the current solution re: the relationship between the bpv functions for seals and seal manifestations, though it avoids this problem, nonetheless argues strongly for a full nlg system (see crooked mechanism for quotes, for example) - in the new version, instead of offering the option of making something an inference rule, shouldn't we just allow _any_ method to be referred to using a property? that would be fun - note the currently somewhat twisted mechanism for setting the label for same_negative in description templates, and the rigid mechanism we use to get to the global object; this argues for a way to include special logic for structures based on part-to-whole relationships - in our theoyr, fuse rep area with soc for rep org group; though if we combine these with named graph parts and try to use the set operations that that allows, we may run into completeness or recursivity problems - in the new version, will we be able to inversely traverse a method signature? or only properties? - methods signatures provide path traversal (with properties or not), there will have to be a difference between calling them on an object (to get a node result) and including them in a path definition (to include traversal of the path they define in a larger path) - include in path language a way of saying "all other nodes with the same path to this object", for example, for a photo published in a book, get all other photos published by the same book - for fine-grained nlg control: we have various "specifity properties" and "focus properties" on the lexema (?) that refer to something: for example, "miembros de la colección" vs. "miembros" vs. "listado de miembros"; or "D.F." versus "D.F., México" vs. "Distrito Federal, México". - a new concept: trickle-up; when the user sets an option (such as ordering, or viewable field) the configuration should trickle up the hierarchy of superproperties and thus be applicable for viewing classes that have a similar though not identical property - fanatstic example of a case in which it _definitely_ makes sense to have a bit of normal code inference a triple: colleciton size - what about showing or hiding certain grouping options according to context--for example, hiding "in colleciton" grouping option when we're already showing a given collection, and showing it when we're in search results? this seems to argue for considering a collection view to be, from a back-end perspective, just another faceted view Possible language addition - Way of saying, an object bound to a given ruleset must have at least one of these several possible descriptors - Way of setting a default value for a property - Way of establishing a pre-set complex structure for a describable object - Inheritance for RuleSets - Multilingual TextBPV functions - Explicit definition of the objective of a ruleset: fund value, complex value, DO or abstract rulesets...? - Way of having a class that is superclass of both datatypes and normal classes - Allow single descriptor KRRelations to apply properties backwards (create acrs in the opposite direction)...? Perhaps only in some cases, such as when the property doesn't take a literal object? - Sub-descriptions (like sub-lenses) and named descriptions Possible major changes - Consider the thing a declarative programming language - Name it - Use braces instead of XML-style tagshttp://132.216.18.132/64/mp3.20070126.09.00-11.00.m3u - Place lexically-scoped RuleSet elements directly in the RuleSet instead of in wrappers, and allow flexible ordering - Consider declarations in Vocabulary section in a more formal manner, not at all just "convenience" means - Rename Descriptor sections, remove descriptor concept from doc, and make it equivalent to a simple KRRelationRule - Attempt to facilitate, for the programmer, the conception of objects created by the code - Create JavaDoc style documentation system - Declarations of various scopes, including global (for example, for what is currently specialSingleDescRelRule, repository setup options, global inference rules, advanced search paths, field selection and naming [see below]) - Remove need for "default" designations for full, variable and short descriptions - Merge BPVFunctions with non-default DescFragments section? Global decalarations, inferences, path templates - clear declarations needed for inference rules, in order to implement properly - configuration mechanism needed for advanced search options - configuraiton mechanism needed for prioritizing/naming/offering selection of compatible superproperties for descriptions in search results, using them as equivalencies for export to other standards - if we integrate closely with a triple store we'll be able to maybe take advantage of some of its optimized code for fundamental sub-prop and sup-class inferences, no? Refactorings required - Change KRRelations to deal with DOorVals, not GraphNodes - Clean up methods for passing from objects of one graph hierarchy to the other - Change structure and procedure for creating, modifying and deleting stuff - Change terminology: DOorVals - Several classes have methods for setting completeness or initialization, but they're called differently in different places - Urgently need test suite - Reorganize packages, fix visibility, final and abstractness declarations all over - ranges don't propagate over prop hierarchy - make GraphParts part of the wrapper hierarchy and not the low-level graph hierarchy, give them a different name, and maybe give them constructor methods currently elsewhere (like create DO, for example) - Hackiness of web_controler.rb argues for ditching Rails (oh no!) - Hackiness of labels on KRRelations rules argues for using properties instead of relation rules in path definitions, and obliging the creation of inferenced statements when additional model-relevant info regarding a realtion rule must be stored - Unify path definition/selection mechanisms (MultipleKRRR vs. PathToDORule, PathToDO vs. something or other in search(?)) - Unify process of taking one-for-many (when we need just one value from a property on a given resource) - Move GWT classes into several smaller packages - Check out reducing use of instance/static variables instead of accessor methods, especially over class hierarchy - Make sure new names result in shorter class names, killing such beasts as VariableDescTemplateOptsElementReference - Once we're on JRuby and have proper RCP accessed directly from the GWT client, unify client and server "reference" objects. These are part of what will be serialized and passed back and forth from server to client. - Proper error bubbling and tracking, with possible status tracker to provide info for forseeable errors - GWT: separate list view states from list info requests and list configs (see comment in ListViewState); this is essentially a MVC separation issue within the client - GWT: change all events from listeners to sink events, esp. mouseovers, or maybe even jsni mouseovers - GWT: try using internal "hyperlinks" that come with GWT - GWT: make main control states, and re-use control states when possible (such as when going from one list to another) - When designing ordering optimization algorithms, take into account automatic ordering of (unordered) prop values in descriptions - GWT: refactor regionattachables to make them attachable to inner tab pages - GWT: make all WebClientInterface methods static, and maybe other static-y stuff, to avoid having to pass the relevant instance references around Notes on searching algorithm - All values lead back to one and only one describable object--though the path to it may go through one or more intermidiate (complex) values; thus Value objects should store information about the DO they are associated with and the path of SingleDescriptorKRRelations that link them with it - A search result will only be created on DOs in main level SOCs; it should be possible to cache the paths from DOs in secondary level SOCs using internal, automatically created MultipleDescriptorKRRelations, which should also cache auto-generated multilingual text describing the relationship - BPVs need to store their text or image value, language, info on the type of node they refer to, function that created them - Do we need to add extra info to BPV functions to allow the algorithm to correctly compress multiple hits in textBPVs into hits on a smaller number of nodes? Or perhaps the functions themselves should be allowed to generate such information? - Perhaps the algorithm will go something like this: - If two textBPV hits refer to the same node and one is a literal and another is a DO linked to the literal and generated from the default TextBPVFunction of that DO, take the DO hit and ignore the literal hit. (This is a step that may be fine-tuned with additional info provided with TextBPVFunctions.) Then discard all hits along the same path leading to the DOs in main-level SOCs. - If a group of textBPV hits are on a path of literals and complex values leading to a DO, but the textBPVs for the DO do not contain hits, take the hit on the node closest to the DO and discard remaining hits on the outer side of the path. Ignore also hits along the same path leading to the DOs in the main-level SOCs. - If there are MultipleDescriptorKRRelations that shorten the path to DOs in main-level SOCs, use those to build human-readable backtrace text and to group search results - Perhaps we need to include snippets of prose and processing rules in KRRelation definitions in order to create human-readable backtrace text; sort of the equivalent of having to talk about the rule backwards, in a phrase describing a chain of relationships. - For all this to work TextBPVFunctions should only produce results that may describe a node in its totality; obviously this can't be enforced, so it should be emphasized in the documentation - Examples for testing and considering fine-tuning info: person's name and birth/death years, giving "De Tal, Fulano (1910 - 1990)" (need a different procedure depending on where the hit comes from) - To make these work, BPV functions should be able to "defer" hits to the bpv function of another rule, which would mean that if a search hit is received for a result of both functions, the first hit would be ignored and only the hit on the second would be followed - This could be specified via the code within the code block itself - Every basic hit actually has two components: a DO and a single descriptor KR relation that relates the DO to a value - For future retrieval speed, perhaps backtracing MultipleDescriptorKRRelRules need to contain and index extra information (such as any persistent groups the out nodes belong to, or other stuff depending on types of search offered). - MultipleKRRelations may have to provide information about the sort of relationship they're meant to establish. For example, in manifestation-content relationships, we have equivalence; but in MDF we have "additional info" (for stuff like location of convent, for example). This may either be simplified--or complicated--when we implement sub-descriptions - For searches in "other" stuff in descriptions: - Code-less desc templates are executed ahead of time and not cached fully; rather, a marker object is created for the partial information to reference, text and image values generated by code in the template are cached, and an index that registers which more-generally-available df lables appear in the description - This means that code-ful templates must be pre-compiled to Ruby code, executed to create code-less templates, which are then "mock-executed", to create not descriptions but rather the partial information that needs to be cached; this means that every DO that uses a code-ful template actually has its own unique code-less template associated with it. The extra memory consumption that this implies may be mitigated by comparing and grouping generated code-less templates that are the same. - For actual description creation templates are re-executed in normal mode - Like other functions, templates must register which parts of the graph will trigger re-generation and re-caching of information in order to remain current, and must be re-generated and re-cached as necessary - In order to maintain uniform search algorithms some of the information used in these searches may be graphed - This will allow search results to say, "10 photos with the term 'foo' in the description found", rather than "term 'foo' found in record format used for collection 'bar', which includes 12 photos". I'm not 100% sure the former is better than the latter, however. DescTempalte code execution - Code-ful templates are compiled to Ruby code that itself creates a code-less one - Unique BPV's in any (even code-ful) templates have to be executed and cached once for each node that uses the template, or perhaps more times, if they're multilingual. However if the unique BPV function create identical values for all those nodes, this may lead to a lot of repetition and waste of space ------------- Needed for general instantiation: - sys:SiteOrgCollection, sys:langAlt, sys:MultOrdObjectsSeq, sys:RepositoryArea, sys:FundamentalDatatype, sys:ComplexDatatype, sys:AbstractDatatype, sys:hasGroupLink, sys:LFMarkup, sys:Group - rdf:type, rdf:Bag, rdf:Seq, rdf:Alt, owl:DatatypeProperty, owl:ObjectProperty, owl:Class, rdfs:DataType - Terms in ontology_term [rdf:label, rdf:comment, rdfs:subClassOf, rdfs:subPropertyOf, rdfs:range, rdfs:domain] - Terms in repository_area [swv:hasTitle, swv:hasDescription, sys:hasRepAreaPurpose, sys:hasGroupDomain, sys:hasMembers, sys:SystemThingsAdmin, sys:SharedArchivalThingsAdmin, sys:GeneralArchivalThingsAdmin] - Terms in soc_default [swv:hasTitle, swv:hasDescription, sys:hasGroupDomain, sys:hasMembers, sys:hasSiteOrgPurpose, sys:SecondaryLevel, sys:MainLevel] - Realms, abbreviations, ontologies, repository, RepositoryAreas Other terms that may be loaded normally from system.def - sys:ComputerFile, sys:DigitalImageFile, sys:Filename More rjb ideas: - Access to inner classes Instantiation: Base elements: - Make Realms (without RepositoryAreas) * - Make empty RealmOntologies * - Link external ontologies for Realms * - Make empty Repository * Bootstrap: - Check that sys and swv Realms have been established * - Check that required external ontologies have been declared * - Make undescribed, ungraphed objects for terms required for bootstrapping * - Make empty, undescribed, graphed RepositoryAreas and SOCs that will hold RepositoryAreas, Classes, Properties, and Datatypes * - Instantiate hardcoded rulesets for describing SOC, RepositoryArea, Class, Property, and Datatypes; this means making KRRelations, StructureRules and DescTemplates * (DescTemplates, StructureRules and other details pending) Main instantiation: - Load, describe, model vocabulary (when appropriate, simply add to descriptions of hardcoded terms) - Check that hardcoded vocabulary terms exist in .def files - Load, describe, model empty SOC's (when appropriate, simply add to descriptions of SOCs) - Load and bind RuleSets, make sure everything that needs a RuleSet has one - Load individuals Removed bootstrap step: - Read in and instantiate BootstrapRuleSets for describing SOC, RepositoryArea, Class, Property, and Datatypes; this means making KRRelations, StructureRules and DescTemplates Reformulated bootstrapt step: - Make graph for descriptions of system RepositoryArea, SOCs for Classes, Properties and Datatypes, and bootstrapped Classes, Properties, and Datatypes --------- Reasons for tight integration with t-store - Datatype/language tag problem - Assigning values simultaneously for members of a group - Optimizing database queries - Optimize performance by avoiding "convenience" layer API and understanding how oprations are actually performed - Applying inference rules - Make Jena objects remember the Pescador object they're linked to - Non-duplication of some hardcoded resource facilities (such as rdf:type) - Unify inference processing -------- Low-level graph operations: - Determining a resource's type or types (class or classes)* - Determining the collection a describable object belongs to* - Determining if a describable object belongs to a secondary or a main level SOC* - Determining which repository area an object is in* - Determining the ruleset to which a describable object is bound - Determining a literal's datatype and language - Determining the KRRelationRules that depart from and arrive at a resource, non-inferenced or inferenced/non-inferenced - Answering a request for KRRelations conforming to a specified pattern - Going from an indexed BPV to the generating node (search function) - Determining if a resource is equal to another one or not - Assign a KRRelation to a resource, creating new resources as necessary - Destroying a specified KRRelation -------- An identifier object is linked explicitly to a ruleset and a realm, regardless of how it may have been written In Graph have an index of all URI's to their Pescador objects In Identifier have an index of all identifiers and their Pescador objects Objects and their identifiers - Realm (universally accessible) ==indexed globally== [id] - DescFragmentTemplate (accessible from within the same RuleSet) ==indexed by RuleSet== * [id] - KRRelRule from a Descriptor (universally accessible) ==indexed by RuleSet== * [id / rule_set.id / realm.rule_set.id] - KRRelRule from a KRRelationRule element (universally accessible) ==indexed by RuleSet== * [id / rule_set.id / realm.rule_set.id] - BPVFunction (accessible on objects bound to this RuleSet and in DescTemplates) ==indexed by RuleSet== * [object.id, id] - InferenceRule (throwaway identifier) * - RuleSet (universally accessible) ==indexed by Realm== ** [id, realm.id] - SOC (universally accessible) ==indexed by Realm== ** [id, realm.id] - CompVectorFunction (just refernces a comparisonVector linked an ancestor of the Datatype bound to this RuleSet) *** [id] - comparisonVector (accessible in RuleSets bound to the descendants of this Datatype) *** [id] - DefinitionSet (throwaway identifier) - anchor (internal DescTemplate reference) [id] - Area (internal DescTemplate reference) [id] - Block (internal DescTemplate reference) [id] * RuleSet-level identifiers must not conflict ** Realm-level identifiers must not conflict *** Special conflict restrictions, depends on datatype hierarchy -------- Object indexing and constructor analysis: Realm - Indexado por abbrev en : KRModel - Fábrica estándar : KRModel - Accesible desde : KRModel - Accesible desde : RealmRequirement (casos especiales) ExternalOnt - Indexado por abbrev en : Realm - Indexado por abbrev en : Graph - Indexado por URI en : Graph - Fábrica estándar : Realm - Accesible desde : Realm - Accesible desde : Graph - Accesible desde : RequiredPart (casos especiales) RealmOntology - Vinculado con : Realm - Accesible desde : Realm - Accesible desde : RequiredPart (casos especiales) Repository - Vinculado con : Graph - Accesible desde : Graph - Accesible desde : RequiredPart GraphPart - Indexado por id en : Graph - Indexado por URI en : Graph - Fábrica estándar : Graph - Accesible desde : Graph - Accesible desde : RequiredPart (casos especiales) RuleSet - Indexado por id en : Realm - Fábrica estándar : RuleFactory - Accesible desde : RuleSet KRRelationRule - Indexado id por : RuleSet - Fábrica estándar : RuleFactory - Accesible desde : RuleSet - Accesible desde : HardcodedKRRelationRules (casos especiales) ComparisonVector - Indexado por id en : DataType - Fábrica estándar : RuleFactory - Accesible desde : DataType SOC - Indexado por id en : Realm - Fábrica estándar : DOModifier - Nodo en grupo : Una de las RepositoryArea - Accesible desde : Realm - Accesible desde : HardcodedSOCs (casos especiales) - Accesible desde : GraphNode correspondiente RepositoryArea - Vinculado con : Realm - Fábrica estándar : DOModifier - Nodo en grupo : SOC "repository_areas" - Accesible desde : Realm - Accesible desde : HardcodedSOCs (casos especiales) - Accesible desde : GraphNode correspondiente Property, ConcreteClass y Datatype - Fábrica estándar : DOModifier - Nodo en grupo : SOC "properties", "classes" y "datatypes" - Accesible desde : Graph - Accesible desde : HardcodedResources (casos especiales) - Accesible desde : GraphNode correspondiente FundamentalValue - Fábrica estándar : Modifier - Accesible desde : GraphLiteral relacionado - Accesible desde : Graph (no implementado) ComplexValue - Fábrica estándar : ComplexValModifier - Accesible desde : BlankGraphNode relacionado - Accesible desde : Graph (no implementado) GraphLiteral, NonBlankGraphResource e hijos - No indexado - Fábrica estándar : Graph - Accesible desde : KRRelation (en la mayoría de casos) - Accesible desde : HardcodedResources (casos especiales) - jNode accesible desde : NonBlankGraphResource, GraphProperty - jNode accesible desde : API de Jena - Objeto recuperable desde jNode: Graph (no implementado) BlankGraphNode e hijos - No indexado - Fábrica estándar : Graph - Accesible desde : el objeto que lo emplea (MembershipBag, MultOrdObjectsSeq, StructuredLangAlt) KRRelation - Indexado indirectamente : con NodesFromKRRelations - Fábrica estándar : KRRelationRule (objeto interno generado y guardado cuando se invoca el método assign) - Accesible desde : NodeFromKRRelation DescriptorMapping - Indexado por nodo y krrRule : Graph - Fábrica estándar : Graph - Accesible desde : Graph - Accesible desde : métodos especiales de algunos DescribableObject (...o tal vez no) Everything that needs to be accessed by id should be indexed by id. Things that need only be accessed by URI can be retrieved internally using KRRelations -------- Hardcoded KRRelRules - has_members - has_type - is_in_soc (reverse of has_members, with a condition) (mult.) - is_in_repository_area (mult.) The ruleset an object is bound to is a property of the object, but is not kept as a KRRelation (Rulesets are not noded, for now.) -------- Procedure for creating descriptions In all cases, for each KRRelation to be modified or created: the information required depends on the type of node being submitted. - when a literal is submitted, a value, and possibly language and/or datatype; - when a complex value is submitted, data for descendent nodes and possibly language and/or datatype; and - when a resource is submitted, the resource. Data read from .def file and written using hardcoded RuleSet - The .def file interpreter constructs KR Model objects, some of whose structures should be mirrored in the KR - The KR Model objects hardcode mappings from the data they contain to data required for creating KRRelations and nodes - The data is checked for validity against input validation rules and structure rules - For out nodes that are values, new nodes are created - The KRRelations are assigned - If successful the calling object procedes with subsequent operations Data read from CSV file and written using RuleSet from .def file - The CSV files are read and cells are mapped, on a general level, to RuleSets, Describable Objects, and modifiable KRRelations - If the mapping does not correspond to available options as set out by RuleSets, an error is thrown - The data is further checked for validity against input validation rules and structure rules - For out nodes that are values, new nodes are created and, for modification, old nodes are destroyed - The KRRelations are assigned - If successful the calling object procedes with subsequent operations Data gathered from used and written using RuleSet from .def file: - KRRelationModPos elements are sent embedded in a DescriptionForMod. - The KRRelationModPos are rendered by the user interface in widgets that capture input. - Data is gathered from the user - The data is checked for validity against input validation rules and structure rules - For out nodes that are values, new nodes are created and, for modification, old nodes are destroyed - The KRRelations are assigned - A confirmation message is sent back to the user -------- .def file element processing left out (for now): - RepositoryArea: GeneralArchivalThings / SharedArchivalThings / SystemThings -------- Ruleset object structure: - SingleDescriptorKRRelationRules as structure requirements - This provides ways of finding nodes over those rules, as well as descFragments - MultipleKRRelations - These also provide DescFragments - Inference rules - BPVFunctions--named and anonymous - Descfragments in the ruleset--named and anonymous Globally indexed - identifiers and their corresponding objects - declared graph URI's - KRRelations - BPValues Notes for organizing KRRelations ================================ A. Extraction - Request arguments: KnownNode, NodeAs, KRRelationRule, Lang - Lang is never unknown - We don't know if the results will be ordered or not - There is no need per se to generate index structures when paramaters don't have results - There is no difference in this procedure for single- or multiple-descriptor KRRelationRules B. Creation - Request arguments: InNode, OutNode, KRRelationRule, Lang, Index - Lang and/or Index may be null - Index structures should be created when they don't exist - The only differences in this procedure between single- and multiple-descriptor KRRelationRules are: - multiple-descriptor do a lot of lookup in the process of establishing concrete relations - only single-descriptor create graph structures, though on doing so they should see which multiple-descriptor relations are created too, and verify graph structures requirements NodesFromKRRelation cases: 1. Unordered, no language restriction 2. Ordered, no language restriction 3. Unordered, with language restriction 4. Ordered, with language restriction Note that inverse traversal can provide the same posibilities as forward traversal Foo -- hasTopic --> (1) Topic1, (2) Topic2, (3) Topic3 Zoo -- hasTopic --> (1) Topic1 Foo->has_topic = ordered results Topic1->has_topic.inv = unordered results has_topic.inv Topic1->has_related_object = unordered results Foo->has_related_object.inv = ordered results Manifestation, content, object @prefix : <> . :obj1 :hasManifestationLink :manifLnk1 . :manifLnk1 :hasManifestation :manif1 . :manif1 :hasContent :photo1 . :manif1 :imageType :negative . :obj2 :hasManifestationLink :manifLnk2 . :manifLnk2 :hasManifestation :manif2 . :manifLnk2 :reproducedFrom :manif1 . :manif2 :hasContent :photo1 . :manif2 :imageType :positiveReprography . :obj3 :hasManifestationLink :manifLnk3 . :manifLnk3 :hasManifestation :manif3 . :manifLnk3 :reproducedFrom :manif1 . :manif3 :hasContent :photo1 . :manif3 :imageType :positiveReprograph . Centro de ciencias aplicadas y desarrollo tec frente a Contaduría a un costado de la DGSCA, de lado izquierdo. Escaleras, mano izquierdo, segundo nivel, al fondo 11:00. ---- Loose ends: - image BPVs, image BPV functions and images themselves* - variableDesc and non-defaultDFs in descriptions* - flatten multiple paths, compare paths - colleciton-level descriptors, rule set that inherits from group base, group links/linked groups - code in templates - missing values - gestor de grupos dinámicos* - nodos ordenados seq - eliminar resultados repetidos por literales vinculados con un obj. desc. por medio de una regla multilingue - eliminar resultados de cosas internas del sistema (?) - default df label for multiple KRRRs (*?) Fixed: - uniqueDF, uniqueTextBPV, uniqueImageBPV and BPVs from MultiText in descriptions ---- Cuestiones fundamentales para la siguiente etapa de investigación 1 - aumentar la capa de abstracción encima de la norma WS, analizar nuestra propuesta desde las DL, estudiar más ejemplos de modelaje para afinarla, definir ontología básica para elementos en dicha capa 2 - mapeo objetos-WS y aspectos fundamentales del lenguaje Sofía: estudiar propuestas existentes de mapeo objetos-WS y mapeo objetos-base de datos relacional, mecanismos de herencia múltiple en lenguajes oo, modelos de programación orientada a aspectos, mecanismos de lenguajes de programación que permiten reutilizar métodos (como Delegates, en C#) 3 - trabajar el lenguaje para definir caminos, integrando aspectos de un trabajo presentado en ESWC y mecanismo actual 4 - estudiar y posiblemente integrar mecanismo presentado en ESWC sobre partes de la gráfica nombradas 5 - obligar la aplicación de reglas de estructuración, algoritmos y api para modificar la gráfica, problemas de concurrencia, permisos y bloquear partes de la gráfica durante la modificaicón, código de verificación de entrada; ¿también sirve el trabajo con DL aquí? 6 - para los puntos 1 a 5: estudiar otros lenguajes de KR como Prolog y Kif 7 - proyectar con detalle las interfaces de usuario para las funciones de la siguinete etapa, entre ellas, modificación de datos, navegador por facetas/búsqueda avanzada, selección de campos disponibles, navegador de colecciones, datos y personalización de los usuarios 8 - integrar mecanismos más avnazados de generación de legnuaje natural; destaca la trayectoria del trabajo en este rubro, de Fresnel, los archivos .def, y las necesidades que se presentan de generar fragmentos de lenguaje entendibles y correctos y describir amablemente caminos en la gráfica 9 - estudiar los algoritmos de búsqueda, sobre todo en relación con un nuevo mecanismo de generación de lenguaje natural 10 - volver a estudiar la optimización de operaciones para acervos grandes; estudiar de forma global las necesidades en este sentido a partir de la proyección de la interfaz de usuario; revisar los mecanismos de almacenaje persistente en bibliotecas existentes como Jena y Sesame, y la forma de integrar la información adicional que aporta la capa de abstracción y construir el almacén de datos funcional que se requiere 11 - refactorar y ampliar el mecanismo para definir plantillas de fichas y opciones de agrupación, ordenamiento, selección de campos, etc., e implementar como componente del sistema 12 - proyectar, de manera muy preliminar y a grandes rasgos, un sistema amigable para diseñar fichas 13 - nueva arquitectura global, que permita componentes cambiables (plug-in architecture) tanto para vocabulario, lógica de empresa, traducción interfaz-modelo y combinaciones de estas áreas; destaca trayectoria del lenguaje .def, limitaciones del planteamiento actual 14 - nuevo marco de aplicación cliente-servidor, integrando plenamente GWT y JRuby, y desechando Rails 15 - refactorar y reogranizar diversos aspectos del código del cliente 16 - diseño en UML de la implementación de todo lo anterior 17 - programación de código y sistemas de prueba de solidez de código (test suites) 18 - montar versiones de prueba con colecciones 19 - realizar pruebas de usabilidad con las nuevas interfaces En todo lo anterior: destaca trabajo ya hecho, conjunción con trabajo de otra gente en áreas afines, y diversos nudos de áreas de trabajo, que se sobreponen. También destaca que el actual proceso de modificar, afinar cosas, es más lenta por la falta de planeación de los detalles que actualmente estamos implementando. - Áreas de trabajo que no pertencen al campo informático: a - Manual de catalogación b - ISAD(G) c - Investigación social a partir de y con relación a colecciones d - Modelaje de colecciones específicas e - Desarrollo de propuestas teóricas sobre los contenidos y soportes Nudos de trabajo: - Imagen e investigación social (c, d, e, a) - Catalogación, modelaje e interfaces de usuario (a, b, d, 1, 7, 19) - Interfaces de usuario, persistencia y optimización (7, 8, 9, 10, 11, 12, 5) - Lenguaje Sofía e interfaces del programador (2, 3, 4, 5, 6, 13) - Implementación (13, 14, 15, 16, 7, 16, 18, 19)