Page 1 of 2
PID Information Types WG
Posted: Tue Nov 13, 2012 4:34 pm
by tobiasweigel
Please find the current draft WG Case Statement always attached to this post (it will be continuously updated).
Your feedback is most welcome! Please feel free to post any comments, suggestions and discussion items to this thread. We will accumulate content and update the working document continuously.
Best, Tobias & Tim
Re: PID Information Types WG shepherd intro
Posted: Sun Nov 18, 2012 6:17 pm
by bethplale
Hi,
I am with the RDA steering group and have been appointed as shepherd to the PID information types candidate working group. I am here to help and help move things along, so feel free to contact me with questions, needs, etc. On behalf of the RDA steering group, we appreciate your effort in this important area!
cheerfully
Beth Plale (plale at indiana dot edu)
RDA Steering Group
Re: PID Information Types WG shepherd intro
Posted: Mon Nov 19, 2012 12:45 pm
by uschwar1
Thanks Beth,
I already got the mail, that I belong to the new mailing list rda-cwg-pidinfotypes@lists.rd-alliance.org, which is the first step of the Todo list of Tobias.
Are you maintaining that list, or who else does it? There is another guy from GWDG, who is interested to join the group.
How are requests like that handled?
Ulrich
Re: PID Information Types WG
Posted: Mon Nov 19, 2012 8:25 pm
by HermanStehouwer
Ulrich: just send me an email 
Herman.Stehouwer _AT- mpi DDDDDDOT nl
Re: PID Information Types WG
Posted: Wed Nov 21, 2012 9:30 am
by tobiasweigel
Dear all,
we have prepared a draft case statement document - please find the current working document always attached to the first posting in this thread.
We would now like to open discussion about the current draft document and like to get your feedback - any comments are welcome! There are several sections which are currently either completely open or where more contributions would be highly beneficial. These include in particular:
3. Engagement with existing work in the area: Anyone knowing of relevant efforts, please help to populate this section!
4.3. Working group operation: The topics of how to achieve consensus and address conflicts are until now undefined. This also includes the issue of how to get a quorum for decision making and the criteria for active participation.
5. Adoption plan: What other activities and actions must be initiated to promote the practical use of our WG deliverables?
6. Initial membership: If there are people missing in this list who would like to join our discussion, please point them to Herman Stehouwer. Note however that we would prefer to have the majority of discussions here in this forum and not on the mailing list so the continuing debate does not fork to two separate mediums.
Best, Tobias & Tim
Re: PID Information Types WG
Posted: Sun Nov 25, 2012 6:39 pm
by llannom
These are comments on the draft Charter as of this date (I didn't find a version number).
I think it is a great start and am anxious to hear if this is considered a good model for a Case Statement (so I can copy it ).
Two minor comments and one larger comment.
o In the first sentence 'augmented with specific information' seems a bit confusing to me because of 'augmented.' As though the id was being enhanced with vitamins. I really think you're talking about id resolution to type/value pairs, although the term 'resolution' does not appear anywhere. Later you use the term 'associated' with etc., which sounds better to my ear anyway.
o I'm pretty sure I know what you mean by profiles but also think it would be wise to define it.
o The distinction between data types and properties seems like a slippery slope to me. By creating a category of PID Information Types (can we call them PITs for this discussion?) you imply that each PID will contain a Data Type for the entity being identified. Is that correct? If so, then you are in the classification business, which is a tricky business, especially for the people creating the ids. If I have a matrix of temperature observations, what is my data type? I know its a matrix and that should be one of the properties that I should be able to discover either from the PID or from some source to which the PID directs me. But do we have a Data Type for temperature observations? Or observations? Or numeric data? The distinction between data and metadata is also problematic, in my view. I think metadata is a relationship, not a type of data.
So I don't think the distinction is needed and will just cause confusion down the road. We can define individual PID Information Types useful in various ways and encourage common usage across communities where appropriate without dividing them into data types and properties. If that sort of distinction turns out to be useful later, it can be done, but don't require it from the start.
Larry
Re: PID Information Types WG
Posted: Mon Nov 26, 2012 1:36 pm
by dgbroeder
Hi all,
First something essential about the scope:
I agree with the comments of Larry concerning the distinction between data-types and attributes.
e.g the difference between data and metadata is a matter of context and perspective “one persons data is another persons metadata”. BTW. what is an article in this context? Anyway I think data-type of objects should not! be in the scope of this group. If I am correct it is covered already by 2 other RDA groups.
We should concentrate on the data-types or rather encodings of object properties: author , URI, checksum, … and try to define an interoperable set, this will be immediately useful in data-management infrastructure efforts.
further
- Maybe it is good to name real projects and communities with the identified stakeholder roles.
- I would also add "EPIC" to "Engagement with existing work in the area"
G.
Daan
Re: PID Information Types WG
Posted: Mon Nov 26, 2012 3:43 pm
by tobiasweigel
Hi Larry and Daan,
thanks for your feedback. I'll answer in detail...
llannom wrote:
o In the first sentence 'augmented with specific information' seems a bit confusing to me because of 'augmented.' As though the id was being enhanced with vitamins. I really think you're talking about id resolution to type/value pairs, although the term 'resolution' does not appear anywhere. Later you use the term 'associated' with etc., which sounds better to my ear anyway.
Agreed, 'associated' is a better phrasing. I'll have another look at the context as well. And yes, the term 'resolution' should defninitely appears somewhere in the doc, it is a key concept!
llannom wrote:
o I'm pretty sure I know what you mean by profiles but also think it would be wise to define it.
Yes, because I am not sure that there is a single understanding of what a profile is (and is not) and whether we are talking about the same thing. So I'll put this on the table:
A profile defines a set of PITs which are mandatory for creating PIDs that conform to that profile. A profile does not mandate that only PITs defined in it are used on a conforming PID (a PID can contain other PITs without violating the profile). The purpose of profiles is to ease implementation of higher-level tools that expect certain information to be there and to provide a minimal form of quality control.
This is what currently comes to my mind regarding profiles. It may still be that I'm missing some obvious difference in understanding, so please extend / correct!
Regarding the data type / property / data vs. metadata perspective:
You are both right, this takes us too far out of scope for this WG. It emerged out of an attempt to define the interaction and boundaries particulary with the type registry WG and also accommodate the needs of existing projects - which we must in fact abstract from. If at all, any conceptual discussions should be part of the data foundation & terminology WG in particular; more likely, they will emerge in discussions across WGs at some point. Given Daan's examples, I would actually claim that things like 'author' and 'URI' are not at the same level of abstraction. There is however no point in going down this road just now - rather it is a crucial point we must deal with as part of the WG work (and answer this particular question in appropriate detail!). For now, PITs must encompass all of these without attempting any classification.
In consequence, I'll cut the distinctions. I'll also include some task that defines the intended role of PID Information Types (PITs) given some exemplary contrasting use cases.
I also think now that as an early WG task, we actually need to agree on a common model for what a PID and its associated information look like, prior to analyzing the use cases.
dgbroeder wrote:
- Maybe it is good to name real projects and communities with the identified stakeholder roles.
- I would also add "EPIC" to "Engagement with existing work in the area"
Yes, I'll include EPIC and write a few words about the overall connection.
Regarding real projects/communities and their stakeholder roles - maybe I'm misunderstanding this, but I'd think this could get very extensive (listing every data center that may potentially benefit from this is a bad idea). Shall we provide a few examples from different communities that are the most likely to be early adopters for their respective community?
Re: PID Information Types WG
Posted: Thu Nov 29, 2012 2:20 pm
by dgbroeder
> Regarding real projects/communities and their stakeholder roles - maybe I'm misunderstanding this, but I'd think this could get very extensive (listing every data center that may > potentially benefit from this is a bad idea). Shall we provide a few examples from different communities that are the most likely to be early adopters for their respective community?
I did not mean listing at the fine grained level of data-centers but more at the level of organizations. So e.g. if there are relevant organizations of data-centers or organizations that push data-management middleware it would be good to have a name and/or a link this would allow us also to look if these stakeholders have some requirements and/or implementations that are of interest for us.. I made this remark because you mentioned the term organizations explicitly.
However maybe the role/actor list is superfluous and we should just say that the outcome of this group will be useful for discussions between data management infrastructure providers and PID service providers helping them to derive at maximum commonality. (or something like that). It could be useful if the mentioned functionality would be the guiding classification and be more elaborate.
NB all talk about an API design and prototype implementation also depend on a choice of a PID service provider, not? or do you see the prototype as a complete PID service.
Daan
Re: PID Information Types WG
Posted: Fri Nov 30, 2012 4:06 pm
by swb
Greetings. I'm finally on board, but I would appreciate an explanation of the purpose of this forum versus the mailing list. Which is to be used for what?
Thank you ... Scott
