<div dir="ltr">Markus,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Mar 31, 2016 at 5:46 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Mark,<br>
<span class=""><br>
On Tue, Mar 29, 2016 at 02:18:04PM -0400, CresitelloDittmar, Mark wrote:<br>
> On Mon, Mar 21, 2016 at 5:54 AM, Markus Demleitner <<br>
> <a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> wrote:<br>
</span><span class="">> Rather than putting some in here, and some in NDCube, I thought it<br>
> best to keep it all together. Do you have another suggestion on how<br>
> to handle this dependency while STC2 is being reviewed?<br>
<br>
</span>I'm afraid I don't have enough understanding of the technical nature<br>
of the dependency -- why doesn't a simple reference to some internal<br>
working draft work for the moment?<br>
<span class=""><br></span></blockquote><div><br></div><div>There isn't an internal working draft to refer to yet, only the UML and vo-dml HTML on volute. This is being worked.<br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> re: Characterisation<br>
> Section 3 is for the ObsDataset extension, and is, therefore, one of the<br>
> specific Dataset types which is pulling in Characterisation. Other types<br>
> (eg: SimDataset if it were cast into this framework), may or may not<br>
> pull in Characterisation, and may or may not want to extend that to<br>
> include other simulation specific characterisation.<br>
><br>
> Perhaps ObsDataset should be moved into the Observation/Experiment<br>
> package-model.<br>
<br>
</span>My main interest is that I can use Dataset without having to process<br>
the entire STC model *in VO-DML*. So, my intereset is that the<br>
various VO-DML documents are independent. If that can be arranged,<br>
I'm not so worried about the rest of the hierarchy.<br>
<span class=""><br></span></blockquote><div><br></div><div>From the VO-DML perspecitive, they are separate models. Char and STC-2 are imported models.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > (4) Talking about Curation.rights: This now has a multiplicity 0..1.<br>
</span>[...]<br>
<span class="">> > [my take: strike AccessRights and make Curation.rights point to<br>
> > RightsType directly -- I don't think the potential benefit of having<br>
> > this kind of thing machine-readable outweighs the cost in terms of<br>
> > complexity]<br>
> ><br>
><br>
</span><span class="">> When you say 'point to RightsType directly', that would not be possible as<br>
> RightsType is a DataType.. it would be an attribute (as it was previously).<br>
> I don't follow the 'machine-readable' part of your comment.<br>
<br>
</span>Well, machine-readable means that having DM attributes for the time<br>
span of the access rights means that a computer can, in principle,<br>
figure out when a dataset will change its status (and with higher<br>
multiplicity, even figure out when that will be). Since I don't see<br>
a use case proportional to the added complexity I indeed proposed<br>
going back to having a plain atomic attribute.<br>
<span class=""><br></span></blockquote><div><br></div><div>OK.. not sure where to go with this. Will give it some thought.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> > (6) I'm not happy with the inflation of places where dataset<br>
> > identifiers can stand. There's now Curation.publisherDID,<br>
> > DataID.creatorDID, and DataID.datasetID. I don't think we're doing<br>
> > our users a service by multiplying the concepts here, even though I<br>
> > admit that each of these have a use case.<br>
> ><br>
> > I'd much rather see an Identifier type:<br>
> ><br>
> > Identifier.kind: (publisher, creator, persistent, ...)<br>
> > Identifier.form: (doi, ivoid, generic-uri, ...)<br>
> > Identifier.value: (well, you know).<br>
</span>[...]<br>
<span class="">> I haven't inflated anything. These are the same set which has been<br>
> in the prior models. I do like the idea of using an Identifier<br>
> type rather than anyURI. Should be more adaptable to evolving<br>
> standards/forms. I would resist the 'kind' attribute. As I said<br>
> above, these groupings are associated with the dataset by different<br>
> parties and the distinction is pervasive across the existing<br>
> Resource documents.<br>
<br>
</span>...and has lead to much confusion. I frankly don't see that these<br>
different parts of a DM instance will be maintained by different<br>
people. And for the publisher it's much easier if they have one<br>
central location for all the various identifiers -- which also helps<br>
making clear their relationships. It also helps when, for instance,<br>
the creator has assigned both a DOI and an IVOA creatorDID assigned<br>
to a dataset.<br>
<span class=""><br></span></blockquote><div><br></div><div>Yes.. but I think we cleared up the confusion about the different IDs<br></div><div>(which would not change if they were bundled in a central location ).<br></div><div>I can see how a central location for the identifiers would be convenient<br></div><div>in some use cases, but in my opinion, it makes more sense to keep them<br></div><div>with the bundle of metadata assigned by the Party.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
> > (7) Publication<br>
> ><br>
> > Here, we should be explicit about what the publication reference is.<br>
> > Much as I would like the bibcode to rule supreme forever, this is<br>
> > almost certainly not what is going to happen. Either this gets a<br>
> > form attribute as in (6) or we say "This should be a URI with a<br>
> > scheme; use bibcode: for bibcodes, doi: for DOIs. In a pinch,<br>
> > non-URI, freetext references are ok".<br>
> ><br>
><br>
> Isn't this what 2.9.1 says? Is there specific language you'd like changed<br>
> there?<br>
<br>
</span>Well, perhaps something like:<br>
<br>
This should be interpreted as a URI. Bibcodes should use the ad-hoc<br>
schema bibcode: (unless Alberto protests loudly), dois should use the<br>
form with the doi: schema. Freetext references are discouraged. If<br>
they are used nevertheless, they must not start with "[a-zA-z]+:" to<br>
ensure they are not interpreted as URIs.<br>
<span class=""><br></span></blockquote><div>OK.. <br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> (10) Having said that, I think orcids will become a smash hit in the<br>
> > near future if they aren't one already. Hence, I'd add<br>
> ><br>
> > identifier<br>
> ><br>
> > to the Party attributes. The stuff on defining identifiers as in (7)<br>
> > applies here, too (if we go the URI way, we should say whether we<br>
> > want orcid:0000-... or <a href="http://orcid.org/0000-.." rel="noreferrer" target="_blank">http://orcid.org/0000-..</a>.)<br>
> ><br>
> ><br>
> Can you elaborate? Having an ID at the Party level could be<br>
> confusing.. as an individual (me/you) could have different ID<br>
> depending on the Role we are playing at the time. That is why I<br>
> left them up at the Role extensions (Publisher.publisherID).<br>
<br>
</span>Well, our orcid would presumably be the same, no? And even if I have<br>
a different id when I'm a publisher than when I'm a creator: I'm not<br>
sure it helps if the attributes have different names. Isn't it<br>
enough that the two items differ by role?<br>
<br></blockquote>If a scientist takes an orcid for use in tagging publications/datasets to associate them with the scientist,<br></div><div class="gmail_quote">then wouldn't the orcid be associated with the Scientist role? or Author? They would map to the same <br></div><div class="gmail_quote">person. Would a Party want more than one orcid? to separate fields of study or funding vs science?<br><br></div><div class="gmail_quote"><div>I really think it is a Role thing. I agree that the attribute name could be consistent. There is no need to retain "PublisherID" for an ID under in the "Publisher" class. It could be moved to Role proper, but in this work, there didn't seem to be many roles which require an ID, so I left it to the extensions. Perhaps you have other use cases in mind?<br><br></div><div>Would that work for you?<br></div><div><br></div><div>Mark<br><br></div></div></div></div></div>