Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MCF format: Simple algorithmic conditionals #20

Open
luke-jr opened this issue Jul 1, 2019 · 4 comments
Open

MCF format: Simple algorithmic conditionals #20

luke-jr opened this issue Jul 1, 2019 · 4 comments

Comments

@luke-jr
Copy link

luke-jr commented Jul 1, 2019

Sometimes content deletion is cleaner if entire scenes are removed, but if the scene is a mix of different categories, you might have no way to remove the surrounding time. So some simple combination conditions seem desirable too.

@ocram
Copy link
Contributor

ocram commented Jul 1, 2019

Thank you!

but if the scene is a mix of different categories, you might have no way to remove the surrounding time

Could you give an example where this problem might occur? If there is violence first, then nudity, then profanity (i.e. a mix of categories), and I want to block all three, why wouldn’t that work? Which surrounding time would you want to remove that would currently not be removed?

So some simple combination conditions seem desirable too

The reasoning behind the specification was that the MCF format should just be a plain description of the content that is there and could be filtered, and any conditional processing would be applied by the tooling, e.g. the current web application, which should already do that.

@luke-jr
Copy link
Author

luke-jr commented Jul 1, 2019

For example, a conversation might be "Hi. We had sex. Then I killed her."

If you're removing both sex and violence, it doesn't make sense to leave just "Hi" - the whole conversation should be removed.

@ocram
Copy link
Contributor

ocram commented Jul 2, 2019

But what about leaving out only the sentence in the middle? Doesn’t make as much sense, either, right? And that would be just one category, which is the basic and regular case.

So we would need those “conditionals” practically everywhere, i.e. every single annotation of filterable content would need a description of what other parts might depend on it, and which might need to be filtered as well so that everything makes sense.

After all, this could become much too complex for the format to store and for the annotators to describe. Not sure if that’s worth it. With existing bleep censors and their beep sounds, we have the same situation: You obviously don’t get 100% of the information anymore, and something might not make as much sense anymore, but that’s okay because in exchange you get the content you want with the parts filtered as desired.

@luke-jr
Copy link
Author

luke-jr commented Jul 2, 2019

Support for such conditionals doesn't mean everyone needs to use them.

I don't agree that there should be a "cost" to decent content...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants