atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Radley (JIRA)" <>
Subject [jira] [Commented] (ATLAS-1690) Introduce top level relationships
Date Thu, 13 Apr 2017 11:32:41 GMT


David Radley commented on ATLAS-1690:

Thank you very much [~Stefhan] for the quick thorough feedback. REsoponding to you feedback
in <<david >> tags :
Page 1:
•		 “Metadata stores store metadata” re-write this to “Metadata repository stores
metadata” as it is less confusing. <<David agreed>>
•		 Suggestion to replace ‘metadata entity’ with ‘metadata object’, as the term
object is more generic. <<David agreed>>
•		 “Relationships include when Glossary Terms are linked to each other, assets mapped
to Glossary Terms and asset metadata linked together.” Are there types of relationships
between metadata objects that are excluded from this scope? <<David Category to term,
glossary to term, as we bring in classification schemes - there will be more relationships.
I just wanted to give a flavor of the the relationships ) >>
Page 2:
•		 “As a 1 When this document refers to Glossary Term – it is referring to those described
in Jira 1410. Page 2 of 9 Glossary Term is linked to an asset, we need to be aware that there
are 3 owners, one for the Glossary Term one for the asset and one for the relationship. This
document proposes a design that allows relationships to be considered in this way.” Does
this state that we consider relationships as ‘first class citizens’? As such that the
relationship between two objects becomes an object on its own, with a unique identifier and
potentially additional metadata?  <<David yes for the loose relationship case>>
•		 “When this document refers to Glossary Term – it is referring to those described
in Jira 1410.” This exact sentence was already mentioned as footnote on page 1. <<David
good spot I will remove >>
Page 5:
-		 “Relationship constraints can have an attribute name and a reverse attribute name, but
there is no label for the relationship itself – the relationship name.” What about synonym
relationships? <<David I am thinking of handing these semantic relationships in the
glossary document. My thoughts at the moment are that we would model all semantic relationships
as bidirectional relationships in the type system. For synonyms, I wonder if we could have
a many to many relationship specifying the glossary term synonym as both ends of the relationship
- this is a great unit test case for this item! >> What would then be the attribute
name and the reverse attribute name? <<David synonym>> 
-		 With regards to the Bidirectional relationships example. It would be: ‘A person has
a home address’/’A home address is of a person’. The ‘has a’ / ‘is of’ are two
directional relationships that would always need to be kept in sync. <<David So the
has-a and is-of relationships are semantic - so not in this doc. I think we should model semantic
relationships as bidirectional type we would knot the 2 ends togetherin ot
he one relationship.  >> ‘A home address is a address’. A more accurate example
of a bidirectional relationship would be ‘First name is synonym of Given name’ / ‘Given
name is synonym of First name’ <<David I am thinking of these as other examples of
bidirectional relationships>>
-		 With regards of the styles of relationships, perhaps its good idea to adopt the terminology
o		 Hierarchical relationships (inheritance) 
o		 Equivalence relationships (synonyms/is a) 
o		 Associative relationships (related to / loosely coupled) 
For inspiration see: Morville, Peter and Rosenfeld, Louis (2002)
Page number 203, page 225, Definition ‘thesaurus’: A controlled vocabulary in which equivalence,
hierarchical, and associative relationships are identified for purposes of improved retrieval.*
* Guidelines for the Construction, Format, and Management of Monolingual Thesauri. ANSI/NISO
Z39.19–1993 (R1998).

See also Figure 9-12. Semantic relationships in a thesaurus (Page number 204, page 226).
See also Semantic Relationships (page number 215, page 237)

<<david - I see these as different sorts of semantic relationships. These are different
to semantic classification, relationships around classification schemes and relationships
between structural metadata. This document is concerned with the base structural metadata
relationships - i.e. relationships the base types system is aware of. This is more of uml
class diagram world of classes, objects and associations; so this document is talking of the
uml style associations - this will be the foundation on which the other relationship types
can be implemented. does this make sense?>>   

Page 7:
-		 Delete functionality. This is crucial as it will allow to cope with changes in the metadata
objects, and relationships provided by other metadata repositories (e.g. other atlas instances).
-		 With regards to the discussion point on endpoints. Endpoints should not be updated / modified
when working on relationships. The relationship should point to the object and subject identifier
without impacting those objects in any way. A separate mechanism should be responsible for
interpreting the relationships and if needed adjusting/updating the associated objects. E.g.
collapsing the assigned classification into the subject or one of the endpoints of the subject
(e.g. assigned information view). <<david - agreed - we are scoping this document to
the base type system relationships>>.
Page 9:
-		 On ‘1 to 1 relationships’: I do not understand why this would be an issue, if you
would define the relationship object independently of the endpoints. In that way, both endpoints
need to exist (otherwise, you will not even be able to select them) before you can create
the relationship. Only the relationship object will then be created pointing to the identifiers
of both the subject and object. <<david but how can you create the 2 objects without
the relationship being in place. To do this you would need to create all 3 at the same time
- as creating any one of them by itself is invalid; or we need to tolerate an invalid state
for a time. Am I missing something? We can to 1 to 1 optional relationships as you say.  >>

> Introduce top level relationships
> ---------------------------------
>                 Key: ATLAS-1690
>                 URL:
>             Project: Atlas
>          Issue Type: Improvement
>            Reporter: David Radley
>            Assignee: David Radley
>              Labels: VirtualDataConnector
>         Attachments: Atlas Relationships proposal v1.0.pdf
> Introduce top level relationships including support for 
> -many to many relationships
> - relationship names including the name for both ends and the relationship.

This message was sent by Atlassian JIRA

View raw message