Document Classification?

[sm]

Document Classification?

This topic comes up from time to time, but not consistently. I thought it would be a good idea to start a discussion on the topic to help gain better insight to the customers interested and their use cases. Some folks are genuinely interested in using PartsLink for documents, others are interested in something a bit lighter than PartsLink as a mean of not only classifying documents, but also enhancing the browse and search capabilities to make documents easier to find.

My goal is to build a little momentum on this topic and start building a business case for supporting document classification in Windchill. Please reply with you or your company's desires in this area to help gauge the level of interest. The more you can share the better.

If you do not want to share publicly, you can always send me a Private Message (PM) and I'll keep the information confidential.

-Scott

[BrianToussaint]

Hi Scott,

We are going to be looking into and hopefully implementing ParstLink this year. I had never even thought of this as a way to classify our documtents. Currenlty we put multiple documents into Windchill for approval routing. However if we could classify ones like test reports or vendor packages, that could make it more than just a file that is searchable or looking in a folder for all machine related test reports. Not having used PartsLink yet, have only seen a demo of it, I do not know all the capability or use of it, so I could not tell you specifically how we would want to classify them yet. However, I do see that it could be very beneficial.

Brian

[GKelly]

Hi Scott,

We are also implementing PartsLink and rolling it out to the company in October 2015. We are well down the path of testing and utilizing PartsLink and see tremendous value in being able to utilize this functionality for Documents. Without this functionality today, we resort to creating multiple sub document types. We do this because the different document types have different attributes critical to identifying what the document is and what it is used for. The downfall to subtyping a document is discovered while creating a new document and trying to decide what document, out of the 20 plus document subtypes, the creator actually wants to create. If the document is created with the wrong document subtype, you basically need to delete the existing one and recreate a new one. If we have classification functionality, the creator simply edits the document and points it down a different classification branch. If we could use classification for documents, we would have 3 main document types and capture the remaining identifying attributes using Classification.

[cc-2]

Hi Gregg

same with me. I solved the classification problems by created new subtype but it also help with the authorisation.

I can have 2 different subtype in the same folder and different role/usergroup have different authorisations. How is it managed when using Partlink ?

[mdebower]

We did much like you, and created a number of document subtypes, and we got around the long list in document creation by using OIR rules.  We created OIR rules that disabled the document subtype at the ORG level and then a second OIR at the Context level to enable it.

You can create a denial OIR by specifying a lifecycle that doesn't exist.

[ChrisPLM]

Hi Marc

this was what I was thinking. I think this is the best way.  Have a data model that allows flexibility.  Windchill is very flexible in that respect.

One can control the Create, Read etc... authorisation individually.   While a user may only create a limited number of subtype, he can still read a much larger number and be able to link them to wtpart and other docs to create the relationship.

I have never been a great fan of PartLinks (granted I have never been an end user of PartLinks) but it seems to me that is an extra layer to create differentiation instead of creating that differentiation at the root.  It would seem an ideally tool for companies whom data models are a bit of a mess, so that layers that sits on top of it bring some organisation but that does not fix fundamentally the problem.  (Please do not throw stone at me....)

In addition, I wonder how can partlinks parameters can be linked to a workflow. Is that as straightfoward than an attributed of Documents (be it Doc or EPMDoc) ?

[soerton]

We have decided to minimize the number of type and instead, create an Document Category attribute to differentiate the documents from each other.

[cc-2]

Hi Stephen

glad you found an agreement within your business. If Workflow and ACL are the same for all the different document classes that you now control with a parameter, I suppose this will be fine.  Hopefully this remain the same.

In the event in the future you need to go back to more subtype. You can always mass export those files and parameters and mass upload into new doucment with different subtype. The drawback is that you lose the history

Best regards

[phetherington]

Hi Scott

We have recently purchased Windchill with PartsLink and are currently defining our parts classification structure. We would also like to use PartsLink for classifying our documents but we understand that this isn't possible. Are PTC planning to allow PartsLink to be used for document classification in a future release? One idea that is being discussed is to create a WTpart for each document so that we can use the PartsLink classification, however there is some concern about the potential implications of this. The alternative seems to be to create a separate but similar structure for classifying documents but this seems a lot like duplication. Any advice would be welcome

Regards

Paul

[ykumar]

Hi Scott,

Did you make decision on when Document classification will be enabled in Partslink (which version, timeline)?

I have a customer who has understanding that classification is enabled for all Object types in Windchill 10.2 but I am not able to find any documentation around it.

Thanks

Yesvant

[sm]

It is still in the backlog, but has not been prioritized high enough to be considered for a future release. If you are interested in seeing this capability in Windchill, please vote up the idea named Document Classification: Classify wtdocument with PartsLink. The more votes it has, the higher its ranking will be.

[zgodula]

Arriving a little late to the party, but we are also looking into a way to do this currently, since it cannot be done with PartsLink.

Everything is currently in our development environment, but we've done some testing with two methods to tackle the problem:

1.  PartsLink (Sub-Type of wtPart linked to a wtDocument

We created a generic wtPart sub-type called "Linking Object" that we've classified, and then wtDocuments are linked to the classified wtPart.

This allows us to still use the power of PartsLink, but does require an extra step or two to link to a wtPart.

2.  wtDocument Sub-Types

Much like the earlier comments on this thread, we've explored creating many sub-types to cover our needs for documents.  This obviously requires the end user to have a decoder ring to know exactly what type they need to select.  It can also be an administrative nightmare if each sub-type requires different ACLs and workflows.

We are still in the development stage, but hopefully tthis ideaDocument Classification: Classify wtdocument with PartsLink garners some more votes.

[PatrickChin]

There should be EPMDocument (either in CAD or Arbortext) Classification and WTDocument Classification to match both the product requirements and specification structure.  The ability to compare requirements and specification is absolutely essential for businesses to capture instantly the product gaps (lack of meeting requirements) or reuse of requirements into specifications.