[Dspace-tech] Musings on metadata
Hi, We're experimenting with adding new metadata schemas on DSpace. I come from a computer science background, so I am thinking hierarchically, like DNS and LDAP, where the hierarchies are essentially name spaces with common at the top, moving to more unique at the bottom: . org. example. www. OR dc=org dc=example dc=www Naturally, I want to create a schema in DSpace which look like this: org.example.subject org.example2.subject My library guy prefers: org.subject.example org.subject.example2 Are there any technical reasons why we should use one over the other? Cheers, -- 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
Re: [Dspace-tech] Musings on metadata
On Thu, Jul 18, 2013 at 8:54 AM, Alan Orth 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 -- 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
Re: [Dspace-tech] Musings on metadata
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 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 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++ -- 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
Re: [Dspace-tech] Musings on metadata
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 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 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
Re: [Dspace-tech] Musings on metadata
Yes, it would work either way. You were asking about best practice, though. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- 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
Re: [Dspace-tech] Musings on metadata
Ok, Yeah, now that I realize there are no *technical* reasons (and since it's really about best practice), I will go ask on dspace-general. Cheers, Alan On 07/18/2013 01:21 PM, helix84 wrote: > Yes, it would work either way. You were asking about best practice, though. > > > 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++ -- 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
Re: [Dspace-tech] Musings on metadata
On Thu, Jul 18, 2013 at 01:20:14PM +0300, Alan Orth wrote:
> 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?
I think you could do that, but I'm wondering why. What makes
cg.org1.subject a different data type than cg.org2.subject, or for
that matter, say, dc.subject?
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
--
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
Re: [Dspace-tech] Musings on metadata
On Mon, Jul 22, 2013 at 3:51 PM, Mark H. Wood wrote: > I think you could do that, but I'm wondering why. What makes > cg.org1.subject a different data type than cg.org2.subject, or for > that matter, say, dc.subject? Hi Mark, you certainly have a point there. I'll try to explain one situation in which it would make sense. If the two organizations have different requirements on the schema, you would have to keep them separate. E.g. org1 wants to use org1.foo, but for org2 org2.foo has a different meaning because they're harvested by someone else, who requires that specific meaning (yes, I'm ignoring the concept of dissemination crosswalks here). In a real world scenario, it could be author's keywords for org1.subject, but controlled vocabulary keywords for org2.subject. Regards, ~~helix84 Compulsory reading: DSpace Mailing List Etiquette https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette -- 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
