omeka / omeka-s

Omeka S is a web publication system for universities, galleries, libraries, archives, and museums. It consists of a local network of independently curated exhibits sharing a collaboratively built pool of items, media, and their metadata.
GNU General Public License v3.0
401 stars 134 forks source link

Should vocabularies be hidable in property selector? #91

Closed patrickmj closed 9 years ago

patrickmj commented 9 years ago

Fedora emits RDF, and the vocabs it uses are easily uploaded into omeka S. So I've just imported the vocabs so I can import all the data.

Chances are that installing the plugin should also import those vocabularies.

Having those vocabs there makes sense for the import, but it doesn't make much sense to expose the properties to general adding/editing resources. For example, fedora:computedChecksum and ldp:contains aren't really fit for human editing, though they make sense to import (if those vocabularies have been added to Omeka S)

So, should we put a flag on vocabularies and/or properties to indicate whether they should be available to people editing resources?

jimsafley commented 9 years ago

Chances are that installing the plugin should also import those vocabularies.

I'd prefer that vocabulary import only happen via the import vocabulary form, and that your module recommend vocabularies for import and provide links to the RDF-XML. (Assuming of course that the vocabularies are not absolutely required for the import to work.)

In any case, I don't think we should hide any vocabulary or its members. It doesn't matter that they're not fit for human editing since users don't have to select them from the property selector.

patrickmj commented 9 years ago

It seems odd for the import to require additional steps that are not easily seen. If we know data coming in has x vocab, I don't see why not to make it easy to pull that in, just like we do now with the Zotero element set.

The ability to select or not select was the basic question...Should there be properties that we remove from the options so they don't see inappropriate properties?

jimsafley commented 9 years ago

Should there be properties that we remove from the options so they don't see inappropriate properties?

As I answered above, no, we shouldn't hide vocabularies or properties from resource creators.

zerocrates commented 9 years ago

I think "hidable in the property selector" doesn't really fit with the usecase you described, Patrick. Even if fedora:computedChecksum wasn't selectable as a property, it would already be on the things you imported, so the user would still be able to edit that property on anything that came from Fedora.

It sounds more to me like you want properties that are hidden entirely from the form, or disabled somehow.

patrickmj commented 9 years ago

Yes, that's the point I'm trying to get at. fedora:computedChecksum, e.g., would be imported, but should not be editable by a user. Thus, that property should be hidden or disabled. So, back to the top, should we have a way to say some properties are not available for editing?

The question is can we flag fields as non-editable, (we should, full stop, based on what I see). So yes, hidden and/or disabled properties is what I'm thinking of.

zerocrates commented 9 years ago

Yes, that's the point I'm trying to get at. fedora:computedChecksum, e.g., would be imported, but should not be editable

If this issue is about hiding properties entirely from editing then the title of the issue should reflect that instead of referring to the property selector specifically.

To the point, then:

I'm not convinced that uneditable properties are desirable, and further I'm not sure how we'd actually expose such a feature given the current focus on automatically loading properties from vocabulary source files.

Having the data stored elsewhere and then injected into the json-ld values output for "special" pieces of data seems like a possible alternative if immutability is really vital.

patrickmj commented 9 years ago

Not at all following the complaint about the title of the issue. Is there someplace else that a user can choose properties to edit?

I'm fine with leaving it wide open for editing, so long as we are good with making it easy for users to break their metadata

zerocrates commented 9 years ago

Not at all following the complaint about the title of the issue. Is there someplace else that a user can choose properties to edit?

If you're saying you want to prevent editing those properties entirely, which it's clear that you are, you'd also have to hide/remove/disable the inputs that would automatically appear on the edit form. Merely hiding things from the property selector would prevent creating items with those properties, but allow free editing.

patrickmj commented 9 years ago

ah. yes, my bad. That's also in the mix. Sounds like this doesn't have much interest, at least for the first release.