Helix,
I was only using rubbish examples because I was trying not to bore you
with the details of our complex organization :)
... but basically, there are 15 large, entirely separate
companies/organizations in this loosely-related group of agricultural
research centers (we call it the "CG"). Several of us share one DSpace
installation. In my mind it makes sense to use a
schema/namespace/whatever like:
cg.org1.{subject,author,type}
cg.org2.{subject,author,type}
Would that work? I assume we just need to use the same convention in
our input-forms and XMLUI, etc... Or am I misunderstanding the way it
works in DSpace?
Thanks,
Alan
On 07/18/2013 11:53 AM, helix84 wrote:
> I think I understand now. I don't have a definitive answer, but I can
> offer you my point of view.
>
> You are trying to define different schemata for different
> oraganizational units. A more natural fit in dspace would be to do
> this at the namespace level (the first part, which we wrongly call
> "schema"). So IMHO, a more natural fit for DSpace would be:
>
> org-group1.subject
> org-group2.subject
>
> You may want to consult this on dspace-general or with DCAT, who are
> currently dealing with this kind of thing and may offer better advice.
>
>
> Regards,
> ~~helix84
>
> Compulsory reading: DSpace Mailing List Etiquette
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
>
> On Thu, Jul 18, 2013 at 10:37 AM, Alan Orth <alan.o...@gmail.com> wrote:
>> Helix,
>>
>> Perhaps it was a poor example. As a sysadmin I of course abhor www as well,
>> but it was an easy example to illustrate DNS hierarchy; "mail.example.org."
>> would have worked as well for demonstration purposes. :)
>>
>> To clarify, I'm naturally more comfortable with a format like this:
>>
>> org.group1.subject
>> org.group2.subject
>>
>> Where "org" is a large, common parent organization, and group1 and group2
>> are autonomous groups in this organization. Each group will have their own
>> special, non-overlapping subjects, special terminology, authors, etc.
>>
>> The alternative, as my librarian suggests, is:
>>
>> org.subject.group1
>> org.subject.group2
>>
>> Are there any technical merits to using one convention over the other? We
>> had previously been polluting DC with things like dc.xzysubject.subject,
>> which is what we want to move away from.
>>
>> Thanks,
>>
>> Alan
>>
>>
>> On 07/18/2013 11:13 AM, helix84 wrote:
>>
>> On Thu, Jul 18, 2013 at 8:54 AM, Alan Orth <alan.o...@gmail.com> wrote:
>>
>> org.subject.example
>> org.subject.example2
>>
>> Hi Alan,
>>
>> this is the principle behind Dublin Core, which the DSpace metadata
>> schema is generally based on. The second part from the left (element)
>> is less specific, while the third one (qualifier) is more specific.
>>
>> Since DNS and LDAP use the same principle, I don't really see how you
>> came up with the first one. If that's based on "www" being the same
>> value in the third part from the left, there's no real reason for
>> that. A web server FQDN doesn't really have to start with "www" (and
>> arguably shouldn't, see e.g. no-www.org for reasons), so I see this
>> particular convention more as a coincidence than a rule.
>>
>> Just to make sure, can you give a specific example of such metadata in
>> your repository?
>>
>> Regards,
>> ~~helix84
>>
>> Compulsory reading: DSpace Mailing List Etiquette
>> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>>
>>
>> --
>> Alan Orth
>> alan.o...@gmail.com
>> http://alaninkenya.org
>> http://mjanja.co.ke
>> "I have always wished for my computer to be as easy to use as my telephone;
>> my wish has come true because I can no longer figure out how to use my
>> telephone." -Bjarne Stroustrup, inventor of C++
--
Alan Orth
alan.o...@gmail.com
http://alaninkenya.org
http://mjanja.co.ke
"I have always wished for my computer to be as easy to use as my telephone; my
wish has come true because I can no longer figure out how to use my telephone."
-Bjarne Stroustrup, inventor of C++
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
