custom membership predicates
52 views
Skip to first unread message
Adam Wead
Apr 15, 2016, 3:47:15 AM4/15/16
to pc...@googlegroups.com
Hi all,
I can remember this being discussed a while back, but I don't remember what the present status is.
Using Hydra::Works as an example, I can aggregate FileSets under /members with the hasMember predicate. What if I wanted to create my own predicate to distinguish different kinds of members? In Hydra, the /members indirect container is already established, so this would be in addition to, and another indirect container on the work, i.e.
/work/members
/work/others
I can't remember if this is kosher with PCDM, or if there's different way to do this.
…adam
I can remember this being discussed a while back, but I don't remember what the present status is.
Using Hydra::Works as an example, I can aggregate FileSets under /members with the hasMember predicate. What if I wanted to create my own predicate to distinguish different kinds of members? In Hydra, the /members indirect container is already established, so this would be in addition to, and another indirect container on the work, i.e.
/work/members
/work/others
I can't remember if this is kosher with PCDM, or if there's different way to do this.
…adam
Esmé Cowles
Apr 15, 2016, 1:15:33 PM4/15/16
to pc...@googlegroups.com
Adam-
What are the other members? I think in general we've said it would be better to use hasMember for them all, and attach properties to them to differentiate them. Ben's scenario was multiple digitized files meaning a single Work had multiple FileSets, and there needs to be some way of telling the FileSets apart. Is your scenario similar? Or are you talking about child Works or some other kind of different member Objects?
-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.
What are the other members? I think in general we've said it would be better to use hasMember for them all, and attach properties to them to differentiate them. Ben's scenario was multiple digitized files meaning a single Work had multiple FileSets, and there needs to be some way of telling the FileSets apart. Is your scenario similar? Or are you talking about child Works or some other kind of different member Objects?
-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.
Adam Wead
Apr 15, 2016, 2:15:04 PM4/15/16
to pc...@googlegroups.com
This is similar to Ben's scenario. I need to differentiate a bunch of FileSets. It's for the for AIC's Hydra head. You have an art work, or an exhibit, which will have multiple digitized files, both images and text-based, but the files need to be differentiated three different ways: representations, preferred representations, and documents. In their proposed PCDM model, they're doing this via predicates, but you're saying a property on the FileSet could be used. I'm also wondering about adding an additional rdf type to distinguish them.
…adam
…adam
Stefano Cossu
Apr 15, 2016, 3:04:46 PM4/15/16
to Adam Wead, pc...@googlegroups.com
It may be worth noting that the differentiation is not in the FileSet itself, but in the relationship of the FileSet to another resource.
E.g.
<asset1> a pcdm:FileSet .
<artwork1> pcdm:hasMember <asset1> .
<artwork1> aic:hasRepresentation <asset1> .
<agent1> pcdm:hasMember <asset1> .
<agent1> aic:hasPreferredRepresentation <asset1> .
That is why using properties in the FileSet to characterize it is not viable.
Of course one can say that aic:hasRepresentation is a subclass of pcdm:hasMember, but Hydra itself has no notion of RDFS inference (AFAIK) so this relationship between the two properties should be hard-coded in Sufia, I guess, or all relationship explicitly stated.
I am not sure whether indirect containers would help here or just add complexity. Can one not just create a relationship without creating indirect containers?
Stefano
--
Stefano Cossu
Director of Application Services, Collections
The Art Institute of Chicago
116 S. Michigan Avenue
Chicago, IL 60603
E.g.
<asset1> a pcdm:FileSet .
<artwork1> pcdm:hasMember <asset1> .
<artwork1> aic:hasRepresentation <asset1> .
<agent1> pcdm:hasMember <asset1> .
<agent1> aic:hasPreferredRepresentation <asset1> .
That is why using properties in the FileSet to characterize it is not viable.
Of course one can say that aic:hasRepresentation is a subclass of pcdm:hasMember, but Hydra itself has no notion of RDFS inference (AFAIK) so this relationship between the two properties should be hard-coded in Sufia, I guess, or all relationship explicitly stated.
I am not sure whether indirect containers would help here or just add complexity. Can one not just create a relationship without creating indirect containers?
Stefano
Stefano Cossu
Director of Application Services, Collections
The Art Institute of Chicago
116 S. Michigan Avenue
Chicago, IL 60603
Stefano Cossu
Apr 15, 2016, 3:21:28 PM4/15/16
to Adam Wead, pc...@googlegroups.com
Graphical references of what we are trying to achieve are in the links below.
v1.0: only "simple" digital assets, i.e. one asset is related to a group of files derived from the same source
https://drive.google.com/open?id=0B0PHJTgoU3bkSFBUdnJ1ZWRWSDA
v1.1: support composite assets, aggregations of multi-part assets (e.g. an X-ray image made up of individual tiles and an overall stitched image - each of these is a separate aictype:asset/pcdm:FileSet
https://drive.google.com/open?id=0B0PHJTgoU3bkbFYyWW5lRzVlXzg
I actually had some great live feedback during this LDCX session: http://ldcx2016.sched.org/event/6Ws7/11a-edm-dpla-map-pcdm-iiif-alignment - that having been a quite fast-paced conversation, it may have not left much room for simmering, but in broad lines it looked like our ontology aligned with PCDM and HydraWorks.
Thanks,
v1.0: only "simple" digital assets, i.e. one asset is related to a group of files derived from the same source
https://drive.google.com/open?id=0B0PHJTgoU3bkSFBUdnJ1ZWRWSDA
v1.1: support composite assets, aggregations of multi-part assets (e.g. an X-ray image made up of individual tiles and an overall stitched image - each of these is a separate aictype:asset/pcdm:FileSet
https://drive.google.com/open?id=0B0PHJTgoU3bkbFYyWW5lRzVlXzg
I actually had some great live feedback during this LDCX session: http://ldcx2016.sched.org/event/6Ws7/11a-edm-dpla-map-pcdm-iiif-alignment - that having been a quite fast-paced conversation, it may have not left much room for simmering, but in broad lines it looked like our ontology aligned with PCDM and HydraWorks.
Thanks,
Robert Sanderson
Apr 15, 2016, 4:11:30 PM4/15/16
to pc...@googlegroups.com
But if it wouldn't be correct to assert the information against the FileSet (e.g. if the FileSet had one role in one Object and a different role in a different Object), then new predicates seem like the way to go.
Rob
Rob Sanderson
Information Standards Advocate
Digital Library Systems and Services
Stanford, CA 94305
Stefano Cossu
Apr 15, 2016, 5:27:50 PM4/15/16
to Robert Sanderson, pc...@googlegroups.com
Good point. In an ideal world, I would just let Hydra assign a specific relationship such as aic:hasPreferredRepresentation and let an RDFS reasoner, e.g. a triplestore, infer the pcdm:hasMember relationship (actually the property hierarchy is aic:hasPreferredRepresentation < aic:hasRepresentation < pcdm:hasMember).
But since Hydra does not query a triplestore, if I want to get all the pcdm:hasMember relationships for pcdm:Object X, Hydra would need to have the inference rules hardcoded for querying or add the super-properties automatically (which also assume some hard-coding).
Stefano
But since Hydra does not query a triplestore, if I want to get all the pcdm:hasMember relationships for pcdm:Object X, Hydra would need to have the inference rules hardcoded for querying or add the super-properties automatically (which also assume some hard-coding).
Stefano
Adam Wead
Apr 15, 2016, 6:41:56 PM4/15/16
to pc...@googlegroups.com
Hydra has the ability to assign arbitrary relationships using its ActiveRecord-style relational mappings such as :has_many and :has_and_belongs_to_many. These are then indexed into solr, and are persisted as triples on the resource without using any of the management principles of LDP.
pcdm:hasMember however is a predicate explicitly managed via LDP indirect containment, or at least this is how the Hydra stack is doing it via Hydra::PCDM, Hydra::Works, and up into Curation Concerns and Sufia. The benefit is that instead of querying the external triplestore to get my relationship information, I just have to look under /members and there they are. I'm not sure it's appropriate in PCDM to use a pcdm:hasMember predicate *without* doing so using containment. There's nothing preventing you from doing it in Hydra, but I couldn't be assured that it would be causing problems elsewhere because of how that predicate is used. Is there anything in the PCDM Rulebook that says hasMember must be used via containment?
Using the tools in ActiveFedora, you can create additional LDP-managed predicates, but that's outside the scope of what Sufia and CurationConcerns currently provide. You can create them within the application, but they'd need to be wired-up in order to use them.
…adam
pcdm:hasMember however is a predicate explicitly managed via LDP indirect containment, or at least this is how the Hydra stack is doing it via Hydra::PCDM, Hydra::Works, and up into Curation Concerns and Sufia. The benefit is that instead of querying the external triplestore to get my relationship information, I just have to look under /members and there they are. I'm not sure it's appropriate in PCDM to use a pcdm:hasMember predicate *without* doing so using containment. There's nothing preventing you from doing it in Hydra, but I couldn't be assured that it would be causing problems elsewhere because of how that predicate is used. Is there anything in the PCDM Rulebook that says hasMember must be used via containment?
Using the tools in ActiveFedora, you can create additional LDP-managed predicates, but that's outside the scope of what Sufia and CurationConcerns currently provide. You can create them within the application, but they'd need to be wired-up in order to use them.
…adam
Stefano Cossu
Apr 16, 2016, 6:17:37 AM4/16/16
to Adam Wead, pc...@googlegroups.com
To my understanding, PCDM membership and LDP containment are disjointed and independent concepts that may or may not live together. Most notably, ldp:contains is one-to-many, while pcdm:hasMember is many-to-many. pcdm:Object and pcdm:Collection are subclasses of ore:Aggregation.
I understand that Hydra uses LDP containment to manage PCDM membership, but it seems to me more a convenience choice than compliance with a mandatory rule; a parallel structure rather than one depending on the other. Am I correct, PCDM masterminds?
So if Hydra is set up to create indirect containers for each pcdm:hasMember relationship I would follow that path (maybe a bit burdensome, but there may be other advantages as you mention). But if I have to create an indirect container for each of the additional properties (aic:hasRepresentation, aic:hasPreferredRepresentation, etc.) I am concerned that this may start to tax the repository considerably.
Bottom line, would it be a reasonable solution to have Hydra create pcdm:hasMember with related LDP container automatically for each "pseudo-subproperty" such as aic:hasPreferredRepresentation, as well as the other superproperties (in this case aic:hasRepresentation), but without creating extra containers for each of these properties?
Thanks,
Stefano
On Fri, 15 Apr 2016 14:41:54 -0400
I understand that Hydra uses LDP containment to manage PCDM membership, but it seems to me more a convenience choice than compliance with a mandatory rule; a parallel structure rather than one depending on the other. Am I correct, PCDM masterminds?
So if Hydra is set up to create indirect containers for each pcdm:hasMember relationship I would follow that path (maybe a bit burdensome, but there may be other advantages as you mention). But if I have to create an indirect container for each of the additional properties (aic:hasRepresentation, aic:hasPreferredRepresentation, etc.) I am concerned that this may start to tax the repository considerably.
Bottom line, would it be a reasonable solution to have Hydra create pcdm:hasMember with related LDP container automatically for each "pseudo-subproperty" such as aic:hasPreferredRepresentation, as well as the other superproperties (in this case aic:hasRepresentation), but without creating extra containers for each of these properties?
Thanks,
Stefano
On Fri, 15 Apr 2016 14:41:54 -0400
Esmé Cowles
Apr 16, 2016, 11:18:56 AM4/16/16
to pc...@googlegroups.com
I think you've got a couple of options that don't depend on creating extra containers and proxies.
You can use hasMember for all the FileSets, and just have a property called hasPreferredRepresentation that points to the FileSet you want to use. Plum does this now, in the old model where a Work represents a book and it has 200 or however many FileSets that represent each page. The FileSets are members of the Work, and we have a property pointing to the one we want to use as the preview.
Since in practice FileSets are going to be members of only one Work, you could also add an rdf:type statement to the preferred FileSet, and then do something like ObjectBehavior#filter_files_by_type[1] to find it.
-Esmé
1. https://github.com/projecthydra-labs/hydra-pcdm/blob/master/lib/hydra/pcdm/models/concerns/object_behavior.rb#L50
You can use hasMember for all the FileSets, and just have a property called hasPreferredRepresentation that points to the FileSet you want to use. Plum does this now, in the old model where a Work represents a book and it has 200 or however many FileSets that represent each page. The FileSets are members of the Work, and we have a property pointing to the one we want to use as the preview.
Since in practice FileSets are going to be members of only one Work, you could also add an rdf:type statement to the preferred FileSet, and then do something like ObjectBehavior#filter_files_by_type[1] to find it.
-Esmé
1. https://github.com/projecthydra-labs/hydra-pcdm/blob/master/lib/hydra/pcdm/models/concerns/object_behavior.rb#L50
Jared Whiklo
Apr 16, 2016, 4:32:54 PM4/16/16
to PCDM
Just my two sense and only related to part of this Hydra PCDM discussion. But in my opinion and Islandora Claw's design, PCDM:has member is completely separate from LDP:contains.
For instance to handle objects in multiple collections, we use proxies inside our /members indirect container which apply the PCDM:hasMember property to the parent PCDM:Collection pointing to the resource wherever it might be in the repository. The same will be done with files.
IMHO LDP:contains creates a limitation on how your resources are distributed inside the repository as you end up with a lot of resources all contained inside a smaller set of resources.
But I'm not well versed in the Hydra design.
Cheers,
Jared
Adam Wead
Apr 18, 2016, 2:17:06 AM4/18/16
to pc...@googlegroups.com
So then the question is: what PCDM properties use or require containment? Looking at the wiki [1], I'm seeing two specifically, hasFile and ldp:contains for administrative sets. If hasMember and ore:aggregates do not require it, at least in the context of PCDM, that ought to be explained a bit.
Hydra::PCDM, which is the ruby gem that implements PCDM and is subsequently the basis for all Hydra-based PCDM applications, uses indirect containers for both hasMember and ore:aggregates [2]
Jared Whiklo
Apr 18, 2016, 4:35:39 PM4/18/16
to PCDM
I'll state up front that I sometimes get lost in semantic discussions. So tell me if I seem waaaay off base.
However, from the PCDM wiki I see pcdm:hasFile being a subset of ore:aggregates the same as pcdm:hasMember. So to me that would not require containment.
You are absolutely correct on pcdm:AdministrativeSet requiring containment, but I'm not sure if I have a use case for it. So I could be lacking enough knowledge to say whether that is a good or a bad thing.
As it stands I'm not really clear on much of the ORE stuff, except to say that it seems to require waaaaaay to many objects to make a simple relationship. But I assume that smarter people have select ORE as the basis for PCDM because of good reasons.
cheers,
jared
Nick Ruest
Apr 18, 2016, 4:36:56 PM4/18/16
to pc...@googlegroups.com
Side question; what is the status of pcdm:AdministrativeSet? I thought
we were going to get rid of that. But, I could be way off base there too :-)
-nruest
we were going to get rid of that. But, I could be way off base there too :-)
-nruest
>> <javascript:>> wrote:
>>
>> Just my two sense and only related to part of this Hydra PCDM
>> discussion. But in my opinion and Islandora Claw's design,
>> PCDM:has member is completely separate from LDP:contains.
>>
>> For instance to handle objects in multiple collections, we use
>> proxies inside our /members indirect container which apply the
>> PCDM:hasMember property to the parent PCDM:Collection pointing to
>> the resource wherever it might be in the repository. The same will
>> be done with files.
>>
>> IMHO LDP:contains creates a limitation on how your resources are
>> distributed inside the repository as you end up with a lot of
>> resources all contained inside a smaller set of resources.
>>
>> But I'm not well versed in the Hydra design.
>>
>> 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+uns...@googlegroups.com <javascript:>.
>>
>> Just my two sense and only related to part of this Hydra PCDM
>> discussion. But in my opinion and Islandora Claw's design,
>> PCDM:has member is completely separate from LDP:contains.
>>
>> For instance to handle objects in multiple collections, we use
>> proxies inside our /members indirect container which apply the
>> PCDM:hasMember property to the parent PCDM:Collection pointing to
>> the resource wherever it might be in the repository. The same will
>> be done with files.
>>
>> IMHO LDP:contains creates a limitation on how your resources are
>> distributed inside the repository as you end up with a lot of
>> resources all contained inside a smaller set of resources.
>>
>> But I'm not well versed in the Hydra design.
>>
>> 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,
>> To post to this group, send email to pc...@googlegroups.com
>> <javascript:>.
>> Visit this group at https://groups.google.com/group/pcdm
>> <https://groups.google.com/group/pcdm>.
>> For more options, visit https://groups.google.com/d/optout
>> <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+uns...@googlegroups.com
> <mailto:pcdm+uns...@googlegroups.com>.
> --
> 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
> <mailto:pc...@googlegroups.com>.
Adam Wead
Apr 18, 2016, 5:20:24 PM4/18/16
to pc...@googlegroups.com
RE: hasFile, from the Usage in the wiki: "Links to a File contained by this Object." I don't think you're off base. I just trying to get clarity. From the get-go, the PCDM discussions were centered a *lot* around containment and direct vs basic vs indirect, and LDP principles.
RE: AdminSet, it was put out there from day one in Portland, but as of yet, hasn't been implemented. From recent discussion in hydra, it may be renamed to policy sets. [1]
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.
Robert Sanderson
Apr 18, 2016, 6:01:37 PM4/18/16
to pc...@googlegroups.com
My 2c:
PCDM can be implemented without LDP. hasMember and hasFile are just predicates, that you can create and manage however you want...
If you have an LDP based system however, using indirect containers and ore:Proxies is a good way to do that. Given the number of use cases that require order, and the ease of creating a new proxy compared to patching an existing resource, letting the container manage the predicate seems an easy win. With a solution for sending multiple operations in a single http request, the overhead of the number of interactions required will disappear.
I think AdminSet either needs to go away or to have a solid set of use cases described for it.
Rob
Adam Wead
Apr 18, 2016, 6:28:01 PM4/18/16
to pc...@googlegroups.com
+1
…adam
Nick Ruest
Apr 18, 2016, 7:22:10 PM4/18/16
to pc...@googlegroups.com
Figured I'd force the issue with adminset:
https://github.com/duraspace/pcdm/pull/50
-nruest
>>>> <http://gmail.com/>
https://github.com/duraspace/pcdm/pull/50
-nruest
>>>> <javascript:>> wrote:
>>>>
>>>> Just my two sense and only related to part of this Hydra PCDM
>>>> discussion. But in my opinion and Islandora Claw's design,
>>>> PCDM:has member is completely separate from LDP:contains.
>>>>
>>>> For instance to handle objects in multiple collections, we use
>>>> proxies inside our /members indirect container which apply the
>>>> PCDM:hasMember property to the parent PCDM:Collection pointing to
>>>> the resource wherever it might be in the repository. The same
>>>> will
>>>> be done with files.
>>>>
>>>> IMHO LDP:contains creates a limitation on how your resources are
>>>> distributed inside the repository as you end up with a lot of
>>>> resources all contained inside a smaller set of resources.
>>>>
>>>> But I'm not well versed in the Hydra design.
>>>>
>>>> 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+uns...@googlegroups.com
>>>> <http://googlegroups.com/> <javascript:>.
>>>>
>>>> Just my two sense and only related to part of this Hydra PCDM
>>>> discussion. But in my opinion and Islandora Claw's design,
>>>> PCDM:has member is completely separate from LDP:contains.
>>>>
>>>> For instance to handle objects in multiple collections, we use
>>>> proxies inside our /members indirect container which apply the
>>>> PCDM:hasMember property to the parent PCDM:Collection pointing to
>>>> the resource wherever it might be in the repository. The same
>>>> will
>>>> be done with files.
>>>>
>>>> IMHO LDP:contains creates a limitation on how your resources are
>>>> distributed inside the repository as you end up with a lot of
>>>> resources all contained inside a smaller set of resources.
>>>>
>>>> But I'm not well versed in the Hydra design.
>>>>
>>>> Cheers,
>>>> Jared
>>>>
>>>> --
>>>> You received this message because you are subscribed to the
>>>> 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
>>>> <http://googlegroups.com/>
>>>> <javascript:>.
>>>> Visit this group at https://groups.google.com/group/pcdm
>>>> <https://groups.google.com/group/pcdm>.
>>>> For more options, visit https://groups.google.com/d/optout
>>>> <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+uns...@googlegroups.com
>>> <mailto:pcdm+uns...@googlegroups.com>
>>> <mailto:pcdm+uns...@googlegroups.com>.
>>> To post to this group, send email to pc...@googlegroups.com
>>> <mailto:pc...@googlegroups.com>
>>> <mailto: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+uns...@googlegroups.com
>>>> Visit this group at https://groups.google.com/group/pcdm
>>>> <https://groups.google.com/group/pcdm>.
>>>> For more options, visit https://groups.google.com/d/optout
>>>> <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+uns...@googlegroups.com
>>> <mailto:pcdm+uns...@googlegroups.com>
>>> <mailto:pcdm+uns...@googlegroups.com>.
>>> To post to this group, send email to pc...@googlegroups.com
>>> <mailto:pc...@googlegroups.com>
>>> <mailto: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,
>> <mailto:pcdm+uns...@googlegroups.com>.
>> To post to this group, send email to pc...@googlegroups.com
>> <mailto: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+uns...@googlegroups.com
>> To post to this group, send email to pc...@googlegroups.com
>> <mailto: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,
> <mailto:pcdm+uns...@googlegroups.com>.
> To post to this group, send email to pc...@googlegroups.com
> <mailto:pc...@googlegroups.com>.
> Visit this group at https://groups.google.com/group/pcdm.
> For more options, visit https://groups.google.com/d/optout.
>
>
>
>
> --
> To post to this group, send email to pc...@googlegroups.com
> <mailto: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
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>
> Information Standards Advocate
> Digital Library Systems and Services
> Stanford, CA 94305
>
Jared Whiklo
Apr 18, 2016, 7:27:20 PM4/18/16
to PCDM
This is now completely un-related to the discussion at hand but I thought it might be good to have a better understand of Hydra.
So forgive these Ruby 101 questions.
In the Hydra::PCDM is that (lines 5-9) saying the <:members> <pcdm:hasParent> <:list_source> ?
as a follow-on question
Is the :indirectly_contains method (I think) saying to add a property of ore:aggregates set to the ore:proxyFor of all the :related_objects things?
thanks,
jared
Stefano Cossu
Apr 18, 2016, 8:39:51 PM4/18/16
to pc...@googlegroups.com
I agree too. If Hydra uses
LDP direct or indirect containers to buld PCDM structures in
Fedora, this is perfectly fine and probably the best way to go
about it.
However, I am trying to find a trade-off between the convenience of using LDP constructs and the additional resources that it creates. If no ordering is needed or if there are many resources with only one or two members, that is in my opinion where the additional containers may become a burden more than a convenience. Anybody has a different view on this point?
Stefano
However, I am trying to find a trade-off between the convenience of using LDP constructs and the additional resources that it creates. If no ordering is needed or if there are many resources with only one or two members, that is in my opinion where the additional containers may become a burden more than a convenience. Anybody has a different view on this point?
Stefano
--
Stefano Cossu
Director of Application Services, Collections
The Art Institute of Chicago
116 S. Michigan Ave.
Chicago, IL 60603
312-499-4026
Adam Wead
Apr 19, 2016, 11:21:24 AM4/19/16
to pc...@googlegroups.com
Jared,
ordered_aggregation and indirectly_contains are both ActiveFedora::Associations
When they're used in Hydra::Works:
For indirectly_contains, line 10 is saying create an indirect container at /related_objects that uses RDF::Vocab::ORE.aggregates for the membership predicate. Ex:
<> RDF::Vocab::ORE.aggregates <contained_resource>
Lines 11-13: inserted_content_relation is specifying which predicate links the proxied resource in the container to the real one; class_name specifies which ActiveFedora classes may be contained--which in this case is any base class, so all of them; through is the AF class that's representing the proxied object in the container--we have to use a special one because ::Base isn't sufficient; foreign_key I'm not sure of; type_validator is a service class that will be called when the resource is put in the container. We use that to enforce restrictions about the PCDM model, for example, this container will only work with other PCDM objects and not just anything.
ordered_aggregation is slightly different. It does all the same things indirectly_contains, except through: is defining an additional container that has the ordering information. So, using ordered_aggregation PCDM::Behavior would create containers:
/work1/members
/work2/list_source
/members would be all the resources (unordered) with the hasMember property, and /list_source would contain their order.
If you have any more specific questions, I'd hit up the hydra-tech list. Justin Coyne and Trey Pendragon wrote most of this part of ActiveFedora and would know better than I.
…adam
Reply all
Reply to author
Forward
0 new messages