Non-bibliographic metadata

[Arunendra M. Biswas]

Can DSpace be used as DMS for non-library situations?For e.g,my client, a property dealer maintains details of persons,selling/buying a property and details(perimeter,no. of rooms,address) of the property.

Should I just rename the similar fields in the corresponding messages file or create a separate schema altogether?

Since Title/Accession Code does not exist in case of property, such mandatory fields will have no value in this case.

Suggest please.

[David Bigwood]

Sounds like you want a database, not DSpace. LibriOffice is a free open-source office suite that has a database program.

David Bigwood

dbig...@lpi.usra.edu

Regional Planetary Image Facility/Library

Lunar and Planetary Institute

https://www.facebook.com/RPIFN/

https://repository.hou.usra.edu/

[Arunendra M. Biswas]

No, sir. I want Dspace. Only here, Title will be replaced by Deed No., Author will replaced by Buyer or Seller and so on.

[Fitchett, Deborah]

If your client is only storing metadata (data in the various fields) then DSpace is a bit overkill. But if they’re uploading documents relating to the property then DSpace could make sense.

 

Whether you rename similar fields or create a separate schema really depends on what’s easier for you and your client. I don’t think there’s any “right way”. If most of your fields are similar to the default schema then just rename them. But if most of them are different then creating a new schema is probably best. You can also do both – use some fields from the default schema as well as fields in your own schema.

 

Deborah

--
All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/57c5e558-2e7b-4d93-882d-f6f5113994b9%40googlegroups.com.

---

"The contents of this e-mail (including any attachments) may be confidential and/or subject to copyright. Any unauthorised use, distribution, or copying of the contents is expressly prohibited. If you have received this e-mail in error, please advise the sender by return e-mail or telephone and then delete this e-mail together with all attachments from your system."

[Arunendra M. Biswas]

Thank you. Sorry for not being clear about the document storage. Yes, the client will store documents as well.

A property related document is identified by the year of registration, registration book no., and document no., i.e the combination of these three, in order, should never be duplicate.

Is it possible to do so DSpace?

On Wednesday, June 12, 2019 at 1:39:21 PM UTC+5:30, Arunendra M. Biswas wrote:

[Arunendra M. Biswas]

So, I have created a separate schema for storing property details (Dspace1.png screenshot attached).

The problem is: For a property, there can be 2 parties, E.g. Seller and Buyer. Each party can have 1 to N persons, i.e 3 Sellers and 2 Buyers.

We have created a customized submission form for this purpose where 1st page describes the registration details, 2nd page-person details, 3rd page-property details.

For N persons, I entered details of 1 person, with "Add"-ing for next person every time.

This is very complex. (Dspace_prop2.png attached).

Is there any other way? Like generating a person page, on demand only. If there's one person, only one "Person"-page(page 2) will appear.If there are more than 1 persons, so many times page 2 will appear.

On Wednesday, June 12, 2019 at 1:39:21 PM UTC+5:30, Arunendra M. Biswas wrote:

[Fitchett, Deborah]

I don’t think DSpace really supports metadata to that level of multi-dimensionality.

 

Metadata on an item in DSpace is meant to directly describe that item. So for a property, you could have property.seller and property.buyer – or for more granularity, you could have:

 

property.seller.name

property.seller.address

property.seller.phone

etc

 

These could even be repeatable fields – but if you have eg:

 

property.seller.name = Jo Bloggs

property.seller.name = Sam Christie

property.seller.address = 123 Main St

property.seller.address = 64 High St

 

DSpace has no way of knowing which name belongs to which address. As far as DSpace is concerned the metadata values don’t have any relationship to each other – only to the item.

 

At this point I would strongly suggest taking a step back and looking for some other software that lets you create a proper relational database.

 

Deborah

 

From: dspac...@googlegroups.com <dspac...@googlegroups.com> On Behalf Of Arunendra M. Biswas
Sent: Friday, 2 August 2019 7:21 PM
To: DSpace Technical Support <dspac...@googlegroups.com>
Subject: [dspace-tech] Re: Non-bibliographic metadata

 

So, I have created a separate schema for storing property details (Dspace1.png screenshot attached).

--

All messages to this mailing list should adhere to the DuraSpace Code of Conduct: https://duraspace.org/about/policies/code-of-conduct/
---
You received this message because you are subscribed to the Google Groups "DSpace Technical Support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dspace-tech...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/dspace-tech/f051a5a2-fbf4-40c4-a29b-deeccd9504d6%40googlegroups.com.