Re: [rda-datafabric-ig][rda-collection-wg] Some thoughts on "Data Aggregations" terminology & concepts

12 Apr 2016

Dear Keith, all,
dear, I had to truncate the subject line, because it got to long during
our debate for the RDA list server. I think this is a really strong
reminder to get settled;-)
Dear Keith, all,
dear, I had to truncate the subject line, because it got to long during
our debate for the RDA list server. I think this is a really strong
reminder to get settled;-)
Am 12.04.2016 um 12:41 schrieb ***@***.***:
>
> Ulrich –
>
>
>
> Many thanks for this clear explanation. I also enjoy this type of
> discussion. I have a few points:
>
>
>
> You said:
>
> Alternatively we also can say, we omit the possibility of correctness
> proves and use artificial intelligence. In this case we can just use
> language and, if really wanted, ontologies.
>
> In fact using knowledge engineering does not necessarily preclude
> formality (after all logic is a branch of mathematics) so I believe we
> can have the best of both worlds: the formality and precision of
> formal mathematics and the richness of declared semantics within a
> formal syntax.
>
>
>
You are right here, with knowledge engineering we have a third
alternative, and we should try to get the best of both, or even all
three worlds.
KE can indeed help to decide for example, whether an DO is a collection,
but on the other hand this only helps the collection WG, if the
underlying definition, used by KE, is reductive enough to be used by
correctness provable processes.
Dear Keith, all,
dear, I had to truncate the subject line, because it got to long during
our debate for the RDA list server. I think this is a really strong
reminder to get settled;-)
Am 12.04.2016 um 12:41 schrieb ***@***.***:
>
> Ulrich –
>
>
>
> Many thanks for this clear explanation. I also enjoy this type of
> discussion. I have a few points:
>
>
>
> You said:
>
> Alternatively we also can say, we omit the possibility of correctness
> proves and use artificial intelligence. In this case we can just use
> language and, if really wanted, ontologies.
>
> In fact using knowledge engineering does not necessarily preclude
> formality (after all logic is a branch of mathematics) so I believe we
> can have the best of both worlds: the formality and precision of
> formal mathematics and the richness of declared semantics within a
> formal syntax.
>
>
>
You are right here, with knowledge engineering we have a third
alternative, and we should try to get the best of both, or even all
three worlds.
KE can indeed help to decide for example, whether an DO is a collection,
but on the other hand this only helps the collection WG, if the
underlying definition, used by KE, is reductive enough to be used by
correctness provable processes.
> You said
>
> May suggestion would be to change the definition to: A collection is
> +++referenced by+++ a PID pointing to a digital object consisting of a
> set/list of PIDs/Ids and a set of additional pointers/links and
> metadata together with each PID/Id.
>
> I think we have to be very clear on the difference between an
> identifier (PID) and a navigation. For me a PID is an identifier. I
> do get annoyed by W3C people who insist a URL (named URI) is an
> identifier when in fact it is a navigation path (or address if you like).
>
>
>
I'm not sure whether it would already be sufficient to say 'A collection
is +++identified by+++ a PID' to avoid this problem. Or is more behind
Dear Keith, all,
dear, I had to truncate the subject line, because it got to long during
our debate for the RDA list server. I think this is a really strong
reminder to get settled;-)
Am 12.04.2016 um 12:41 schrieb ***@***.***:
>
> Ulrich –
>
>
>
> Many thanks for this clear explanation. I also enjoy this type of
> discussion. I have a few points:
>
>
>
> You said:
>
> Alternatively we also can say, we omit the possibility of correctness
> proves and use artificial intelligence. In this case we can just use
> language and, if really wanted, ontologies.
>
> In fact using knowledge engineering does not necessarily preclude
> formality (after all logic is a branch of mathematics) so I believe we
> can have the best of both worlds: the formality and precision of
> formal mathematics and the richness of declared semantics within a
> formal syntax.
>
>
>
You are right here, with knowledge engineering we have a third
alternative, and we should try to get the best of both, or even all
three worlds.
KE can indeed help to decide for example, whether an DO is a collection,
but on the other hand this only helps the collection WG, if the
underlying definition, used by KE, is reductive enough to be used by
correctness provable processes.
> You said
>
> May suggestion would be to change the definition to: A collection is
> +++referenced by+++ a PID pointing to a digital object consisting of a
> set/list of PIDs/Ids and a set of additional pointers/links and
> metadata together with each PID/Id.
>
> I think we have to be very clear on the difference between an
> identifier (PID) and a navigation. For me a PID is an identifier. I
> do get annoyed by W3C people who insist a URL (named URI) is an
> identifier when in fact it is a navigation path (or address if you like).
>
>
>
I'm not sure whether it would already be sufficient to say 'A collection
is +++identified by+++ a PID' to avoid this problem. Or is more behind
the scenes here?
>
> You said:
>
> I understand this as a statement about possible counterexamples,……
>
>
>
> It was meant purely to indicate that in collections we have to deal
> with richer structures (syntax) than hierarchies and that not all
> nodes are reachable by simple recursion. However, this is not less
> formal than your original case.
>
>
>
> You said:
>
> 'give me all vertices and edges connected to one of its vertices'.
>
>
>
> With the added semantics I suggested on the edges this can become a
> query –for example ‘only those vertices connected by an edge with role
> ‘is part of’ and temporal duration between 20160101 and 20160331’
>
yes, exactly this type of functions I have in mind. Currently we do not
have anything else as 'role' in our definition in place than 'is part
of'. My suggestion here is to think about overloading this 'is part of'
role with other semantical content in the metadata of a collection. For
example I did this analogously in the collection example of publication
references in publications and the corresponding graphs of it. But we
probably would say to have two different collections if they differ in
this semantical content even if the components would the same by chance.
But as you see, these are interesting questions in the collection WG and
Dear Keith, all,
dear, I had to truncate the subject line, because it got to long during
our debate for the RDA list server. I think this is a really strong
reminder to get settled;-)
Am 12.04.2016 um 12:41 schrieb ***@***.***:
>
> Ulrich –
>
>
>
> Many thanks for this clear explanation. I also enjoy this type of
> discussion. I have a few points:
>
>
>
> You said:
>
> Alternatively we also can say, we omit the possibility of correctness
> proves and use artificial intelligence. In this case we can just use
> language and, if really wanted, ontologies.
>
> In fact using knowledge engineering does not necessarily preclude
> formality (after all logic is a branch of mathematics) so I believe we
> can have the best of both worlds: the formality and precision of
> formal mathematics and the richness of declared semantics within a
> formal syntax.
>
>
>
You are right here, with knowledge engineering we have a third
alternative, and we should try to get the best of both, or even all
three worlds.
KE can indeed help to decide for example, whether an DO is a collection,
but on the other hand this only helps the collection WG, if the
underlying definition, used by KE, is reductive enough to be used by
correctness provable processes.
> You said
>
> May suggestion would be to change the definition to: A collection is
> +++referenced by+++ a PID pointing to a digital object consisting of a
> set/list of PIDs/Ids and a set of additional pointers/links and
> metadata together with each PID/Id.
>
> I think we have to be very clear on the difference between an
> identifier (PID) and a navigation. For me a PID is an identifier. I
> do get annoyed by W3C people who insist a URL (named URI) is an
> identifier when in fact it is a navigation path (or address if you like).
>
>
>
I'm not sure whether it would already be sufficient to say 'A collection
is +++identified by+++ a PID' to avoid this problem. Or is more behind
the scenes here?
>
> You said:
>
> I understand this as a statement about possible counterexamples,……
>
>
>
> It was meant purely to indicate that in collections we have to deal
> with richer structures (syntax) than hierarchies and that not all
> nodes are reachable by simple recursion. However, this is not less
> formal than your original case.
>
>
>
> You said:
>
> 'give me all vertices and edges connected to one of its vertices'.
>
>
>
> With the added semantics I suggested on the edges this can become a
> query –for example ‘only those vertices connected by an edge with role
> ‘is part of’ and temporal duration between 20160101 and 20160331’
>
yes, exactly this type of functions I have in mind. Currently we do not
have anything else as 'role' in our definition in place than 'is part
of'. My suggestion here is to think about overloading this 'is part of'
role with other semantical content in the metadata of a collection. For
example I did this analogously in the collection example of publication
references in publications and the corresponding graphs of it. But we
probably would say to have two different collections if they differ in
this semantical content even if the components would the same by chance.
But as you see, these are interesting questions in the collection WG and
not necessarily in the DFT WG.
>
>
>
> All this has been implemented in Europe with CERIF (Common European
> Research Information Format – an EU Recommendation to member states)
> see http://www.eurocris.org/cerif/main-features-cerif
> and its dependent
> tree of information for details. Although the data model is
> represented in extended entity-relation notation it can be implemented
> in just about any paradigm (logic programming, object-oriented….)
>
It would be also an interesting question, whether the collection WG will
be able to use this and to what extend, but first we need to get the
basics in order in our WG. But we should certainly come back to this.