Closed weiweishi closed 6 years ago
@ualbertalib/metadata @weiweishi I see memberOf type is URI... is this the Fedora URI or the Jupiter URI for the community?
should be Fedora's pair tree URI
just assigning to that member_of_collection
relation visible in ActiveFedora should do all the populating of this correctly for you btw
I'm not sure the end use case for this is. If the use case is for people to do SparQL queries, wouldn't returning the Fedora URI give the user a value they couldn't use? (Firewall in front of our Fedora server)
Probably best not to overthink this.
The broader context here is that we (well, I) compromised the purity of PCDM by adding member_of_paths*. Metadata, reasonably, want to make sure we track membership "the PCDM way" as well, so that's where additionally using memberOf comes in.
Hydra-pcdm is part of the base of our objects, and it is a gem designed by acolytes of the Church of PCDM, and if you use it to track membership via the member_of_collections += object
it will perform such incantations as deemed orthodox by the Church, and write the holy values into the memberOf predicate. It is not for us uninitiated apostates to question the form those values take.
If you write the Fedora URI/URL/IDKs in there, I guess you get nice links between objects? IDK. It's sure not how I'd design a database.
(* I don't really want to step on Metadata's toes, but until and unless we move away from Fedora we're both forced to solve two separate and somewhat opposed problems in one small sandbox. The memberOf setup gets things about as wrong as you can possibly get things in terms of efficient object querying -- PCDM is a bad schema with respect to scalable application design.)
Chatted w/ Weiwei to catch the part I was missing -- we don't want to switch community_id on collections to use memberOf, we just want to track it in a PCDM way in addition to community_id, because the semantics of the two are different (community_id is single-valued for business logic, memberOf is multivalued PCDM orthodoxy, etc), and your original observation was right, we'd want the id in community_id for querying but the URI in memberOf.
@cwant it seems that the collection model only tracks community_id with UAL:Path, did I miss something about the PCDM:memberOf?
https://github.com/ualbertalib/jupiter/pull/311/files#diff-b4bf69fb66a797126928732f8cba0cf8R50
Declared in Hydra::PCDM as predicate Vocab::PCDMTerms.memberOf https://github.com/samvera/hydra-pcdm/blob/5f8375ee41cc40f1b89eb4b66a518ff6f7bd11f7/lib/hydra/pcdm/models/concerns/pcdm_behavior.rb#L50
Not declared explicitly (see Matt's comment). Here is an example of a collection with that property set:
http://uat.library.ualberta.ca:8080/fcrepo/rest/uat/cb/3f/33/d4/cb3f33d4-658a-4593-b10b-83acb2d9ab58
ah, yes, of course it's defined in Hydra. Makes sense. Thanks!
Weiwei Shi
Digital Initiative Applications Librarian University of Alberta Libraries 2-10L Cameron Library Edmonton, Alberta, Canada T6G 2J8 Phone:(780)492-7802 Fax: (780)248-1209 Email: weiwei.shi@ualberta.ca
On Tue, Dec 12, 2017 at 10:44 AM, C . Want notifications@github.com wrote:
Not declared explicitly (see Matt's comment). Here is an example of a collection with that property set:
http://uat.library.ualberta.ca:8080/fcrepo/rest/uat/cb/3f/ 33/d4/cb3f33d4-658a-4593-b10b-83acb2d9ab58
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ualbertalib/jupiter/issues/257#issuecomment-351128609, or mute the thread https://github.com/notifications/unsubscribe-auth/AB8-fuqcH3giSiSrPsTsEBQ9GsEhre7_ks5s_rt8gaJpZM4QeL18 .
Question: