Discussions on Fictional Object

I believe your interpretation of the intent of the fictional object type is correct. Adding an additional type (although it would probably be called something like "fictional object category" type to avoid the "type type" nomenclature) sounds like a reasonable request (although I'm not an admin for this area, so can't help directly).

If you create it in your own base and start using it, it would help your figure out what the appropriate properties are, etc, and then it could be "promoted" to the commons later, preserving the work you did.

Okay, thanks. I don't own any bases general enough to hold this type, so I'll just put it in my drafts for now. Too bad I can't give it any return links from the objects in the commons. =/

Anyway, here's the link. http://www.freebase.com/schema/user/ajedi32/default_domain/fictional_object_class

If anyone has any suggestions for the type please feel free to tell me about them. =)

Hmm... it seems that there are a lot of properties of the "Fictional Object Class" type I created are the same as the properties of the "Fictional Object" type. Should these be delegated properties? =/ The properties and their names are almost identical. On the other hand, wouldn't the object class type hold be the one to master properties rather than the object type? And why would an entity be both a fictional object AND a fictional object class?

Any ideas?

A fictional object is not a class of fictional things, I thought the description and examples quite clear (was there something that made it questionable?).

You should consider adding a property to assert what category a fictional class of objects are: Star Destroyer is a fictional class of fictional spaceships. This would allow us to remove the incorrect typing as a fictional object from the topic of star destroyer.

Finally, you might consider moving your type into a base (fictional universal additions?), no one will be able to add, see or use your type otherwise.

What made the intentions of that type questionable for me was that it was being used by other people to indicate classes of objects, and that there was no Object Class type that could be used instead.

So what you're saying is that you think 'Subclasses' and 'Subclass of' properties would be a good idea?

And no problem, I'll move the type to a base. Before I do though, I want to know what you guys think of my previous question (two above this one). If people start using the type and we decide we need to change those properties later, a lot of data could be lost. I don't think we need the properties to be delegated since I don't think a topic can be both a fictional object and a fictional object class at the same time, but I want to know what you guys think before I start using the type.

The properties could be delegated, but is unnecessary IMO. Simply moving a user-created type such as your fictional class that uses as expected types for its properties commons types, fictional object and fictional universe, these associations will not be changed and the data will not be lost in such a move (since move is a bit of a misnomer, what happens is that a new linkage is created between the fictional universe namespace and your type and the old one, currently /user/ajedi32/default_domain/ will be depreciated, but not destroyed).

My very wise coworker thinks it should be a three-way (or triangular) pattern: Object <-> Class <-> ?Classification? <-> Object

Narya <-> Three Rings <-> Ring <-> Narya

We are unsure what would be the best term for what kind of classification the class should be.

Okay I didn't think they would have to be delegated properties, I just wanted to make sure because as far as I know there isn't a way to convert a delegated property into a master property (or vice-versa). I wasn't saying that moving the type would cause data loss, I was more concerned about whether we would have to change the properties to delegated ones at some point in the future. (Just checking.)

So you're saying that I should create a separate type for kinds of classifications? =/ I'm not sure I understand. Do you mean something similar to the 'Rank' property of the Organism Classification type?

Anyway, I've created a new base called 'Commons Prototypes' and moved the 'Fictional Object Class' type there.

No not rank, check this example out: Super Star Destroyer... So what is it? It's a 'super' class of Star Destroyers with one known named ship, the Executor, but what else is it? It's a spaceship. I think there should be a property that allows us to state that this fictional class is a class of Spaceship. Nenya is one of the class of the Three Rings. It is also a ring and a magical artifact. We wouldn't have to do this if the the type was Fictional Space Ship Class or for Rings of Power.

Possible name of property: "Type of?" "Type?" Doesn't seem quite right. "Category?"

Well, I did run Nenya is of the class of = Three Rings > Rings of Power > Magic Ring through your class/classes of ladder. I suppose you could add one higher category, Ring, but that seems not quite right. Not sure about using Magic Ring as the preeminent class. But Nenya is both of the class Three Rings and a Ring and a Magic Ring and it would be a difficult query to find all the magic rings if you need to go several ply down. One could go the ship named Executor is of a class of = Super Star Destroyer > Imperial spacecraft > Spaceship. I'm torn as to having a hierarchical ladder or using the class property for all of the classes regardless of ranking on a topic.

You might want to ask this on the Freebase discuss about suggestions on modeling these relationships, my head is spinning ;)

Well, I guess it's already set up that way. Another thing I was considering is that there are really two types of object classes: The kind where all objects of the class are nearly identicle (I.E. Imperial Star Destroyer), and the kind where objects of the class have only a few charactaristics in common (Space Ship, Magical Ring). I suppose both of these could be represented by the same type, unless we wanted to assign different properties to them (I.E. The first kind could have height and weight properties, while this would not be practicle for the second kind.)

Although maybe we are over-complicating this. No data model can be absolutly perfect. I think perhaps you're right; we should just wait a while and see how people start using the object. We shouldn't wait too long though because if the object is used widely and we want to make changes later then there could be problems.

Fictional object needs some love I guess.

Maybe the creation and destruction links should be to a kind of Fictional Event CVTs (Destroyed by, Destroyer, Note, Fictional Calendar Date/Time)? Should it have a Fictional Object Type (like we now have for Fictional Setting)? I am guessing I should just get rid of the date created and date destroyed, especially for objects from a universe that has it's own unique calendar (Star Wars, LoTR, Dune, etc.).

Considering the difficulty of modeling fictional dates, I'd say we could omit the date properties altogether, and go with two properties (rather than a CVT) for destruction: Destroyer and Destroyed By (Dumbledore and Gryffindor's Sword, respectively).

+1 for fictional object type. 

+1 for non-CVT Destroyer and Destroyed By. CVTs make everything difficult.

I think two new return types are warranted here: Fictional Object Destroyer (Dumbledore) and...what to call the second, something like Fictional Object Destruction Method (Gryffindor's Sword)?