Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Model] Create Entity data type for cross-entity relationships #149

Open
luis100 opened this issue Oct 23, 2012 · 3 comments
Open

[Model] Create Entity data type for cross-entity relationships #149

luis100 opened this issue Oct 23, 2012 · 3 comments
Assignees
Labels
Milestone

Comments

@luis100
Copy link
Member

luis100 commented Oct 23, 2012

A entity can have a property which is a relation to another entity. For example, the entity Repository can have the following properties with type Entity:

  • Content (which is the content profile of the repository)
  • Events (which is the information to come from the Report API)

The relations can be bi-directional, repository can point to content and content to repository.

@peshkira This can also be used to relate format distribution within content profile with formats or do we need a entity-integer dictionary data type?

@ghost ghost assigned luis100 Oct 23, 2012
@peshkira
Copy link
Member

I think EntityInteger Dictionary or even StringInteger Dictionary is better and simple for the distributions because the introduction of the new Entity FormatDistribution won't spare us the dictionaries.
It will be ContentProfile -> FormatDistribution -> (still needs dictionary to represent the triples)

Don't you think? However, if there is another advantage on the core side, I don't mind changing the adaptor

@luis100
Copy link
Member Author

luis100 commented Oct 23, 2012

I think that making to many entities and entity types will make the knowledge base too confusing and impossible to browse on.

Nevertheless, there is a problem with the EntityInteger Dictionary approach, as there is no assurance that a format that is detected on the content profile will exist as a format. Actually, it should be the DataLinker that creates this relationships when available, but not really sure on how to represent this information...

@peshkira
Copy link
Member

I agree with both arguments.
The problem with the current profile is, that it shows the format distribution (but does not include the format version).
I can improve that in the next version as I have also the mime and the format version. Until then, I will say we use the current dictionary (String String), or a new one.

@ghost ghost assigned kduretec Nov 5, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants