2.0 ?

[dl...@islandora.ca]

Hey folks, I'm back from parental leave and in a new position.  :) I look forward to having more time to be involved.

Just looking through https://github.com/duraspace/pcdm/issues/53 and https://github.com/duraspace/pcdm/wiki/PCDM-2.0

Seems like there's some momentum on 2.0, and I'm definitely late to the party, but do we have to slice off a new version for something that could remain as an extension?

~Danny

[Esmé Cowles]

Danny-

Congrats on all the big life changes!

I think it's worth discussing whether we need to update the core ontology or not.

I think the Hydra implementation experience was that FileSet was really essential for keeping groups of Files organized, and that it was important for it to be separate from Object, to keep the division between the abstract-thing and the bundle-of-files clearly defined. We can't really do the same thing in an extension — we want to say that Objects don't have Files, only FileSets do. So that really needs to be in the core.

The other PCDM 2.0 changes could probably still be extensions. Range/TopRange/AlternateOrder could be a tidy package of ordering extensions, for example.

-Esmé

> --
> You received this message because you are subscribed to the Google Groups "PCDM" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+uns...@googlegroups.com.
> To post to this group, send email to pc...@googlegroups.com.
> Visit this group at https://groups.google.com/group/pcdm.
> For more options, visit https://groups.google.com/d/optout.

[Jared Whiklo]

Because I don't see alot of our resources requiring multiple FileSet(s), could we allow either 

pcdm:Object -> pcdm:File

or

pcdm:Object -> pcdm:FileSet -> pcdm:File

That way those whom need the multiple FileSets can use them, but those who don't can save having to create those extra resources/relationships/triples?

Or is that not a viable option?

Cheers,

jared

[Esmé Cowles]

Jared-

I agree that most resources don't need multiple FileSets, and it's going to add extra overhead to add them when we don't need them.

But I think it makes it a lot easier to develop tools if you have the same pattern, instead of having to support both patterns.

I also think it's hard to know in advance what resources are going to have multiple FileSets. You might go back and re-scan things in higher quality, but still want to keep the old versions. A user might upload a file today, and come back tomorrow and upload another format. And it would be nice to be able to add those new files as additional FileSets, without having to change the definition of the existing resources.

This last point is more abstract, but I think it's important: the PCDM 2.0 proposal is about splitting apart the bundle-of-files role and the part-in-the-abstract role, because those are separate roles, even when you only have a single FileSet. It's just not a big problem when you only have a single FileSet, because there's not a lot of overlap between the data for those two roles.

-Esmé

[Jared Whiklo]

I see what you are saying Esme, but it seems like if we leave the door open to use FileSets or just Files then we can support a broader range of use cases.

I don't disagree that having a fixed model is easier to develop for, but I am unsure that it suits the most obvious use cases we have. Seeing as it (IMHO) is a minority of the use cases, then it seems wrong to force the added complexity onto the rest of the data models.

As for you last point, I'm not sure I fully understood it. But the bundle-of-files vs the part-in-the-abstract, to me wouldn't a "part" be another pcdm:Object where a bundle of files would be a bunch of pcdm:Files? Again, I probably totally missed your point.

cheers,

jared

[Aaron Coburn]

I may be missing something, but wouldn't it be possible to just use ore:aggregates instead of pcdm:hasFile / pcdm:hasMember / pcdm:hasFileSet ?

That would leave the door open to a variety of modeling structures (with or without the FileSet layer). The hasMember / hasFile properties have always struck me as a bit unnecessary since you can infer them based on the type of the target resource.

Regards,
Aaron

[Tom Johnson]

> wouldn't it be possible to just use ore:aggregates instead of pcdm:hasFile / pcdm:hasMember / pcdm:hasFileSet ?

This issue has been discussed at some length at https://github.com/duraspace/pcdm/issues/53#issuecomment-220152085.

I'm happy, maybe even eager, to revisit it... but wanted to make sure we import the points already discussed if we are resurfacing this.

- Tom

On Wed, Aug 17, 2016 at 12:35 PM, Aaron Coburn <aco...@amherst.edu> wrote:

I may be missing something, but wouldn't it be possible to just use ore:aggregates instead of pcdm:hasFile / pcdm:hasMember / pcdm:hasFileSet ?

That would leave the door open to a variety of modeling structures (with or without the FileSet layer). The hasMember / hasFile properties have always struck me as a bit unnecessary since you can infer them based on the type of the target resource.

Regards,
Aaron

> On Aug 17, 2016, at 3:31 PM, Jared Whiklo <jwh...@gmail.com> wrote:
>
> I see what you are saying Esme, but it seems like if we leave the door open to use FileSets or just Files then we can support a broader range of use cases.
>
> I don't disagree that having a fixed model is easier to develop for, but I am unsure that it suits the most obvious use cases we have. Seeing as it (IMHO) is a minority of the use cases, then it seems wrong to force the added complexity onto the rest of the data models.
>
> As for you last point, I'm not sure I fully understood it. But the bundle-of-files vs the part-in-the-abstract, to me wouldn't a "part" be another pcdm:Object where a bundle of files would be a bunch of pcdm:Files? Again, I probably totally missed your point.
>
> cheers,
> jared
>
> --
> You received this message because you are subscribed to the Google Groups "PCDM" group.

> To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+unsubscribe@googlegroups.com.

> To post to this group, send email to pc...@googlegroups.com.
> Visit this group at https://groups.google.com/group/pcdm.
> For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "PCDM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+unsubscribe@googlegroups.com.

[Trey Pendragon]

I'm going to try to respond to both Aaron and Jared at the same time here:

PCDM 1.0 is very simple. Things have things, and some things are collections. That's the ultimate level of flexibility - basically any structure can fit into that.

PCDM 2.0 is the realization that interoperability between systems and structural metadata schemes are only possible if there's a definition of levels of hierarchy and groupings - as we're finally using PCDM to develop systems we've begun to define what those groupings look like while still fulfilling our use cases.

I think this hit home for me the most when trying to map to IIIF, a specification with very precise definitions of what's what in the hierarchy. Mapping PCDM 1.0 to it is impossible - there's no way to tell the difference between what kinds of things you have because there's no standard specified declaration of it. The best you can do is guess by context, and hope your guesses are right.

In PCDM 2.0 though, it's very straightforward (even if you leave off the ranges stuff) because you can tell exactly what kind of "things" you have, and each thing has a role and a place in the hierarchy that is expected and defined. It's more complex - things having things was super easy to think about, and you could never be wrong. However, since you could never be wrong, two institutions were often never the same kind of right.

To Aaron's point: Yes, we could use types instead of predicates. There's a discussion starting at https://github.com/duraspace/pcdm/issues/53#issuecomment-220152085, but I think the major point is efficiency: the use case for "parts" (pcdm:objects in front of filesets) was having an object which has a fileset representing the whole, and then each of the parts as well. There's likely only one fileset, and there's N parts - why should I have to check the type of N parts? If the specification can enable efficiency, I think it's our responsibility to do so.

[Aaron Coburn]

Hello Trey,
Thanks so much for the explanation! It is very helpful to have context for this proposed change.

To me, it seems like simply using the ORE vocabulary will provide significantly greater flexibility w/r/t data modeling without the overhead of additional (for me, unnecessary) repository resources, all while using a pretty mature and widely adopted vocabulary. In terms of efficiency for down-stream applications, I'll be caching aggregated resources as JSON-LD anyway (i.e. with a app-specific @context), so I'm not at all worried about that.

But if the different data model makes this easier to work with in the Hydra/ActiveFedora context, then please proceed with whatever makes sense.

Thanks again!
Aaron

[Andrew Woods]

..Relating to Trey's comment, particularly the statement: "two institutions were often never the same kind of right":

> In PCDM 2.0 though, it's very straightforward (even if you leave off the ranges stuff) because you can tell exactly what kind of "things" you have, and each thing has a role and a place in the hierarchy that is expected and defined. It's more complex - things having things was super easy to think about, and you could never be wrong. However, since you could never be wrong, two institutions were often never the same kind of right.

I suspect this will still be true even with PCDM 2.0. That likely being the case, I would like to flag this as rationale for the notion of "PCDM profiles". Interoperability may be greatly supported by the knowledge that one PCDM-compliant application is using a specific profile.

Andrew 

[Brian Tingle]

I suspect this will still be true even with PCDM 2.0. That likely being the case, I would like to flag this as rationale for the notion of "PCDM profiles". Interoperability may be greatly supported by the knowledge that one PCDM-compliant application is using a specific profile

I think profiles and interoperability are at odds.  Profiles are descriptivist, anything goes, just note what you did.  Either profiles become a whole new language and validation scheme, or they just end up long text documents.  Maybe I've spent too much time looking at METS profiles.

Interoperability, IMHO, needs some degree of prescriptivism, at least in a greater degree than descriptivism.  Just my theory.

To the degree that I understand it, I like the direction PCDM 2.0 is going with pcdm:Object and pcdm:FileSet where the FileSet can be one file, vs. allowing either File or FileSet.

FWIW, in Nuxeo the way we are using it, the Document is the root object with lots of properties.  Documents can contain a sequence of Documents (that is how we support complex objects). All the metadata and files are just properties of the Document.  The property `file` is the main file that Nuxeo uses to create derivatives.  The property `files` is an ordered sequence of files that get saved with the Document, but don't trigger any automation chains and don't get published to calisphere.  Some folks will put the tiff w/o color bars in `file` and put the version with color bars in `files`.  Some folks will put the main TIFF in `file` and put the raw camera files in `files`.  I think in one case we have a PDF in file, and all the tiffs that make the PDF in files.  What you want to show up goes in file, any other files related to the Document you want to preserve can go in files.

If I were mapping to pcdm 2.0; I think my Nuxeo Document would be the pcdm:object, and Document/file would be one pcdm:FileSet and Document/files would be a second pcdm:FileSet?  Is there a way to say that one pcdm:FileSet is the most important one for downstream access derivatives?  

Can files inside the pcdm:FileSet use the ore:Proxy ordering mechanism?

Thanks -- Brian

[Esmé Cowles]

Brian-

I am also somewhat skeptical of profiles in the descriptive sense of documenting how you have used a very flexible standard. But I do think it would be a good idea to have a more detailed specification of how to model certain types of data in PCDM in order to encourage people to model, e.g., books, or image collections, etc. the same way. Ideally, this wouldn't be people working in a vacuum and then documenting what they've done. Having a few different institutions working together on these would be much more likely to land on something everybody could use.

For your mapping questions: I'd recommend using the File Use Vocabulary (http://pcdm.org/use#) to differentiate Files in a FileSet, and to create Objects or FileSets to hold the different Files if you wanted to order them. For differentiating FileSets, there's no equivalent to the File Use for them right now. I think there probably should be, but I'm not sure what the axes of difference are. Maybe it's just a notion of preferred vs. alternate?

-Esmé

[Christina Harlow]

Just butting in to respond to Esmé's point here: 

But I do think it would be a good idea to have a more detailed specification of how to model certain types of data in PCDM in order to encourage people to model, e.g., books, or image collections, etc. the same way.  Ideally, this wouldn't be people working in a vacuum and then documenting what they've done.  Having a few different institutions working together on these would be much more likely to land on something everybody could use.

+1, and I'd be happy to help with this effort in any way I could.

As y'all were,

Christina

[Esmé Cowles]

To kick things off, I've written up some example triples for a simple book with just enough structure, order, etc. to demonstrate how the linkages work:

https://gist.github.com/escowles/8f980af9ccfa839fa37c81cf9e1fc01f

I think this is what we've agreed on, at LDCX earlier this year and other discussions this spring. How does this look to everybody? Is there anything essential missing from the example to demonstrate some part of the modeling?

If we agree that this is a good example, I can open a PR to add it to the PCDM examples directory (https://github.com/duraspace/pcdm/tree/master/examples). But esp. since I just said we need to work together, I thought it would be best to send this out and see if other people think books should be modeled the same way.

-Esmé

[Nick Krabbenhoeft]

+1 to helping out with more detailed models.

We're working with digitized audio and video at NYPL, and common digitization practices create sets of files that don't align easily with digitized books. I roughed out an explanation here.

-Nick

[west...@umd.edu]

A big +1 to having more examples of modeling in action.  I am currently modeling our NDNP newspaper content in PCDM and would be happy to contribute examples (and have them reviewed by others).  I guess this will be part of Christina's and Esmé's/Karen's HydraConnect workshops in Oct.? Looking forward to those sessions,

Josh

[west...@umd.edu]

I haven't been involved in the LCDX and later discussions, but FWIW Esmé's example captures everything I was thinking we would do in modeling books (and more -- I hadn't thought about using ranges to delineate the chapters).  

[Christina Harlow]

Hi all-

Josh- we'd be very happy to have you in the data modeling workshop! We'll touch on some of the things discussed here (but it is not a PCDM workshop, FWIW). I'm ecstatic to say that Tom Johnson + Mark Matienzo (along with myself) are on board to co-facilitate this workshop, huzzah for them sharing their intelligence. I just got listed first because I was able to confirm my involvement first. You can see our working doc for the workshop schedule here:http://bit.ly/HC16DataModelWkshop Happy to talk offline about any ideas, requests, or other you (or others on this list) have for this workshop.

Back to the group: I want to pull back on this discussion for a minute. My apologies.

I read through this thread and related docs again to try to get a sense of what parts of "PCDM 2.0" are where in terms of discussion, proposal, adoption, use, etc. This was originally for my own examples/docs updating. But in doing so, I wondered more than usual about the procedure here for moving forward with PCDM updates (versus keeping things as extensions, or Danny's original question), especially with this grouping of topics. I'll say now, all of this represents some really great work by a number of folks. But keeping this grouping as is for discussions also makes it a little bit harder (to an outsider) to know what proposals are at what stages of adoption or to keep discussions on track for either voting or other.

I'm aware of this page detailing the PCDM Models voting method as outlined here, and this leaves a lot of the pre-voting process open. I'm sure this is intentional. But for this particular group of recommendations, I have the following proposals/ideas for getting a bit more structure in moving these recs into better + separate spaces for community discussion, extension generation or core pcdm approval, and documentation (including examples + best practices). This is particularly for PCDM outsiders like myself who want to be in the right place to discuss these topics, and have each topic get the discussion it deserves without other topics taking away from it.

(again, I apologize if I completely missed something here) 

Proposals for moving forward this 2.0 group of recommendations:

• Can we break out the different decision areas into different Google Group or Github Issue threads (also linking to discussions that already exist)?
• This applies both to this Google Group thread and the related GitHub issue thread. Both jump around a bit, as there are quite a few recommendations grouped into 2.0. Separating threads can better reflect where each discrete proposal is in a the stages of casing / scoping and definition / proposal / voting / documentation. 
• For example, it appears the Work + the Filesets discussions are further along than, say, the Range discussion (which, looking at this thread, is still needing more use cases + discussion of those use cases?).
• I've included a list of what I see as the proposals grouped here at the bottom of this email. I'm happy to follow up with creating or re-jumpstarting existing issues or threads for discussion of each topic - even if the discussion is "We agree this 1 thing is great, lets create a PR and vote already." It'll just help clarify things.
• Is there (and if not, may I create) a place for community meeting notes?
• If so, I'm happy to clean up and add LDCX notes for sessions that are relevant to a wiki section for this. That way, folks who weren't at LDCX (or other meetings) can see what discussions happened, and feel better empowered to take part in online discussions.
• We can add to this community meeting notes section whenever the PCDM committers are in one place and going to have discussions that effect the community.
• We could also add a link of repository issues/discussions to watch (Hybox, Islandora-CLAW, Sufia 7) for PCDM in action discussions.
• Could we clarify the role of examples within this 2.0 review, discussion, and approval process? In particular, could we make different areas (subdirs in the examples dir, perhaps) for examples of the current, accepted model and examples of proposed additions or extensions to the model? And then discuss each example using Github issues?
• I know how many people follow the examples instead of reading the model/official documentation, and how those folks then might miss that some of the examples include proposals still in stages of review, taking those proposals as given. I'd hope the above structure would help use avoid someone taking a proposal as a community-accepted decision.
• With the above, and area discussions to occur, we could perhaps let that work guide us to what profiles could look like for PCDM?
• Profiles don't need to be limiting (I understand Brian's point earlier), but some ideas of recommended or proposed usage for different resource types, if nothing else, helps crystallize what a person is thinking and helps make the discussion better.

I apologize for the long email, and I understand if folks think this unnecessary. I just wanted to put this out there in case this appeals to anyone else when talking about 2.0, as I know it would help me better engage.

Thanks, 

Christina

Proposed subthreads/break out topics wrapped up in 2.0:

• Remove Works from the Hydra-Works extension (not in PCDM now regardless)
• See this Hybox discussion
• As a side note, quite a lot of really important discussion happened on the Hybox issues. Its great discussions, but perhaps does a disservice for folks just watching the PCDM issues/listserv. At the least, we should be linking to them for further PCDM work where it overlaps or becomes a case of "community discussion decided".
• See this email thread from Sanderson which had no responses
• Not sure if this is included anywhere in 2.0, but we should confirm it / see if it effects others who aren't using Hydra or Hydra-Works
• Add Fileset to PCDM (moving it out of Hydra-Works) + confirm its relationship to "Part" Objects
• This is pretty far along in discussion + scoping.
• Could include request for adding hasFileset to PCDM as well, which seems less certain.
• I see where it was mentioned in Hybox issues
• It was also discussed in passing on this 2.0 thread
• Will this effect including Fileset the class in PCDM, and so become a different thread?
• Could also include the Fileset typing, File ordering, supporting more File discussions occuring in the listserv.
• There is also the have an Object abstraction above each Fileset discussion, which was heavily discussed at LDCX
• see this Google Groups discussion on Filesets in Curation Concerns
• see this GH Issue Discussion point around Filesets
• see this Sufia 7 discussion
• See this LDCX discussion - are there others to link to from LDCX?
• Adding Range (and relevant subclasses) to PCDM
• See this thread, particularly questions of use cases beyond IIIF interop
• Request more use cases?
• See the examples included in this very listserv thread (thanks Esmé!)
• PCDM RDFS versus OWL?
• This came up in this 2.0 GitHub Issue, and it seems to have mostly gone for staying with RDFS. But perhaps still worth a separate discussion.
• Ordering - nothing seems to be changed here, except requests to use iana:prev in documentation versus iana:previous... confirm?
• Profiles
• this seems a good discussion topic on its own, for deciding what these should be, how they relate to best practices, where they are discussed before being added to the wiki, etc.
• Downstream effects of the above
• What does this mean for Hydra-Works? Islandora CLAW? Other?
• How does this effect the LDP projection for PCDM, and what needs to be written up for that?

[Esmé Cowles]

Christina-

Thanks for your suggestions — a lot of those sound like good ideas to move this discussion forward. My thoughts are:

- I would be happy to break out the separate issues you outline into separate issues. That's probably a more constructive way to approach them and avoid big wide-ranging discussions like this one!

- I don't think there is any place to put community meeting notes, but creating one sounds good to me. The github wiki is an easy place to put them for now, but if there's somewhere else you think would be better, that would be fine too.

- I don't know about having multiple areas for current vs. proposed examples. I think having the current examples merged in, and including changes to the example files to a PR that would also change the ontology might make sense, and keep the example discussion with the ontology discussion. Or putting proposed examples outside github (like in a gist, or google doc, or whatever), which I think also helps make it clear that it's not demonstrating the accepted ontology.

- Either way, I think the role of the examples is to demonstrate a shared understanding of the best way to model particular use cases. Ideally, if we had examples for books, newspapers, and other work types, then a system that supported all of those use types would be consistent with all of the examples. I tend to think of profiles being multiple ways of doing the same thing you can pick from. Is that how everyone else thinks of profiles?

-Esmé

[Brian Tingle]

On Friday, August 19, 2016 at 6:23:26 AM UTC-7, Esmé Cowles wrote:

... I do think it would be a good idea to have a more detailed specification of how to model certain types of data in PCDM in order to encourage people to model, e.g., books, or image collections, etc. the same way.  Ideally, this wouldn't be people working in a vacuum and then documenting what they've done.  Having a few different institutions working together on these would be much more likely to land on something everybody could use. 

makes sense, if you can get out ahead of it, (and then maybe bake these models into the standard) it will be a big win for interoperability.

 

For your mapping questions: I'd recommend using the File Use Vocabulary (http://pcdm.org/use#) to differentiate Files in a FileSet, and to create Objects or FileSets to hold the different Files if you wanted to order them.  For differentiating FileSets, there's no equivalent to the File Use for them right now.  I think there probably should be, but I'm not sure what the axes of difference are.  Maybe it's just a notion of preferred vs. alternate? 

I think in the case of mapping from Nuxeo; the blob in `file` an all the blobs in `files` would just go in the same `pcdm:FileSet` 

[Robert Sanderson]

+1 to breaking it up into separate discussions, and especially keeping the hydra specific implementation concerns in hydra space. 

--

You received this message because you are subscribed to the Google Groups "PCDM" group.

To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+unsubscribe@googlegroups.com.

To post to this group, send email to pc...@googlegroups.com.
Visit this group at https://groups.google.com/group/pcdm.
For more options, visit https://groups.google.com/d/optout.

--

Rob Sanderson

Semantic Architect

The Getty Trust

Los Angeles, CA 90049

[Christina Harlow]

Thanks, Esmé. Some preliminary responses below, because I don’t want to be that person that recommends lots of plans of actions but doesn’t help implement:

>- I would be happy to break out the separate issues you outline into separate issues. That's probably a more constructive way to approach them and avoid big wide-ranging discussions like this one!

Rad! So I have two questions then for the group:

1. Does anyone have issues with breaking up this discussion of 2.0, and having those discussions happen in GitHub Issues?
2. Does anyone see something we should add to that topics list (I’ve cut down my mega-long email to the proposed list at the bottom of this message)?

If we’re good to proceed this route - and I’d propose we wait to move until at least Tuesday, just so we don’t miss out on points from those who have better work/life balances than us folks emailing about models on a weekend - I’m happy to help where I can, Esmé (for example, I’m happy to add links to relevant docs/other discussions for each issue). Otherwise, I’m thinking you’ll break it up because you have the best grasp on what all is included in 2.0.

>- I don't think there is any place to put community meeting notes, but creating one sounds good to me. The github wiki is an easy place to put them for now, but if there's somewhere else you think would be better, that would be fine too.

I think the GH Wiki would be a great place to add these. Again, I’ll wait for any for responses until at least Tuesday then add the space, add the LDCX 2016 notes, and then ping the Google Group back on a separate thread for responses/updates/etc. I think I can add PCDM GH repo wiki pages. If folks are okay with me adding it.

>- I don't know about having multiple areas for current vs. proposed examples. I think having the current examples merged in, and including changes to the example files to a PR that would also change the ontology might make sense, and keep the example discussion with the ontology discussion. Or putting proposed examples outside github (like in a gist, or google doc, or whatever), which I think also helps make it clear that it's not demonstrating the accepted ontology.

Yeah, it could be separate areas or another method, I’m pretty impartial to the method. Perhaps the last option you mention is best: list examples outside the PCDM GH repo (gist is great) until accepted in the ontology, then have it merged at that point (or update existing examples in the PCDM GH repo). If that sounds okay, I’ll document it somewhere in the wiki as well. Again, if that sounds okay with the group.

>- Either way, I think the role of the examples is to demonstrate a shared understanding of the best way to model particular use cases. Ideally, if we had examples for books, newspapers, and other work types, then a system that supported all of those use types would be consistent with all of the examples. I tend to think of profiles being multiple ways of doing the same thing you can pick from. Is that how everyone else thinks of profiles?

I think I agree, yes. Having profiles as a separate discussion topic (as proposed below) would be a good place to discuss further + plan action items on specific profiles being moved forward. I have lots of ideas about this I’m excited to share + bring others into.

Thanks!

[Christina Harlow]

And I’d hope breaking up into separate threads might help approach Danny's original extension question, as it might be easier to figure out what particular patterns the group wants in PCDM core, versus what might be best served as extensions (due to it being technology-specific, like Hydra, CLAW, IIIF, etc.) or other.

Sorry, Danny, if this totally doesn’t help though.

You received this message because you are subscribed to a topic in the Google Groups "PCDM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pcdm/Ep1Cty2JDx4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pcdm+uns...@googlegroups.com.

[Daniel Lamb]

This helps greatly Christina.  Having smaller more focused conversations leading to eventual procedure for approval are exactly what I was hoping for.

~Danny

To unsubscribe from this group and stop receiving emails from it, send an email to pcdm+uns...@googlegroups.com.

[Mike Giarlo (Google Groups)]

+1 to using issues and wiki pages in the PCDM GitHub repo to move this along. Thanks, Christina!

-- 
Michael J. Giarlo

Technical Manager, Hydra-in-a-Box project

Software Architect, Digital Library Systems & Services

Stanford University Libraries

mjgi...@stanford.edu

+1 (206) 402-4473

---

From: pc...@googlegroups.com <pc...@googlegroups.com> on behalf of Christina Harlow <cmha...@gmail.com>
Sent: Sunday, August 21, 2016 14:13

To: pc...@googlegroups.com
Subject: Re: [pcdm] 2.0 ?

[Trey Pendragon]

+1. Thanks Christina!

> +1 to breaking it up into separate discussions, and especially keeping the hydra specific implementation concerns in hydra space.

Agreed, but hopefully this gives us a chance to identify what issues are hydra-specific too.

[Trey Pendragon]

Esmé's created new issues on the Github repository:

#59 Add a FileSet class
#60 Add AlternateOrder, TopRange and Range classes
#61 Stick with RDFS or switch to OWL
#62 Remove the Work class from the Works extension

[Christina Harlow]

Great, thanks! Downstream effects of those will probably be covered in the discussion, or be an action item in the outcome, so that’s covered. Ordering + Range were combined (makes sense, sorry I didn’t see that before), so they’re both covered.

Profiles remains, but that might be better discussed after we get some traction/decisions on the outstanding issues? Or keep this as a discussion point on the Google Group for now? I’ll just break it out as a new Google Group topic, if that’s okay, to get ideas on what profiles we want to aim for, and some profile areas / object types people already are working on or would be requesting.

I’ll create a Meeting Notes area of the wiki and add the relevant LDCX notes. I’ll include points links to the meeting notes captured in the ‘Prior Work’ section (on the homepage as well). 

Thanks all,

Christina

[Christina Harlow]

Here’s the wiki page for community meeting notes: https://github.com/duraspace/pcdm/wiki/PCDM-Related-Meeting-Notes

 Let me know if you see any issues.

Thanks,

Christina

From: <pc...@googlegroups.com> on behalf of Trey Pendragon <tre...@gmail.com>
Reply-To: <pc...@googlegroups.com>

You received this message because you are subscribed to a topic in the Google Groups "PCDM" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/pcdm/Ep1Cty2JDx4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to pcdm+uns...@googlegroups.com.

[Esmé Cowles]

Christina-

There were already comments coming in on the first few issues I created, and I realized I didn't have a concrete outcome for a profiles issue, so I didn't create one. Feel free to create an issue if you can frame a good question, or create a new thread if that makes more sense.

And thanks for making the suggestion to break out these questions into their own issues. There's been a ton of comments on those github issues already, so I think it's already resulted in much better discussion than what was happening in the big combo issue.

-Esmé