Portal, complete and utter newbie

[Anders]

Hello

Forgive me for asking such a simple question. But I just don't understand portal basics. (And further more I use a swedish copy of FM 4.1, headache...)

I am planning a small database. Maybe no more than 50 records. Each record will contain something like a title, an abstract and keywords. Each abstract is, of course, uniquely connected to its title. But the keywords may (or may not) be related to more than one record.

I see no upper limit to how many keywords each record may contain, though it's not likely that each record will contain more than 5 of them.

Repeated fields seems to be a stupid thing, only thing sillier is me who just don't get it. How do I connect a record in Db A to one or two or "as many as there is" records in Db B (the keywords-db)? If I want to add a keyword, how do I avoid adding another instance of the same into Db B - or not adding a non existing but needed one?

Hey I have been upgraded from Junior Member to Member. How could that be. I'd say Adolescent Member at most

[Moon]

I will assume that Database A contains records with a field that you can enter keywords, and that Database B contains records, each of which has data that has more than one keyword associated with it.

Given this setup, here is what I would do:

In Database B, set your keyword field as Text, indexed For the example name the field "Keywords". Then in Browse mode, go to the first record and type the records keywords in the Keyword field, with a carriage return between each word. This creates a multi key field in Database B.

In Database A, create a global text field, and name it "Keyword Selector". Then create a relationship to Database A such that Keyword Selector in Database A equals Keywords in Database B. Create a layout that includes the Keyword Selector field and a portal using this relationship and populate it with the fields you want displayed from each record in Database B. The portal will display all records matching the keyword you type into the Keyword Selector field.

Hope this matches your needs.

[Fitch]

It would help to know how you intend to use these files. Do you really need a separate database for keywords? Do you even need keywords at all? Could you just search on the text of the abstract? Without knowing what you have in mind for the end use, it's hard to recommend a solution here.

But so as not to be totally useless:

It seems like you could use just one file. Your keywords can be in a standard text field, separated by carriage returns.

Then make a global field, which could be a value list, and a relationship global::keywords. A Go To Related Record script and/or button would show you the matching records.

[djgogi]

Yes, right

you should do an revision of your project.

As soon as you start defining entities involved in your project you run into challenge of attributes. An attribute can be thought as a field on a record whereas the entity is the subject of the record as a whole.

So, you should ask yourself a question:

Keywords is just an attribute or is it an entity, and if so what are it's attributes?

My opinion is that it is only an attribute, so I'll suggest you to use methode Fitch already gave you.

Dj

[Anders]

Hello

You can read more on what I want to achieve here:

http://www.fmforums.com/ubb/ultimatebb.php?ubb=get_topic;f=12;t=000574

Should I use Relating fields (probably not), Relationships and/or portals. I'm starting to wonder whether Filemaker is the best solution at all.

Thanks

Anders

[Fitch]

I see now that what you are talking about is a classic many-to-many relationship. On one side, many titles; on the other, many keywords. So how to join them? The answer is typically a third file to store the join information. (The most common scenario is probably the invoices / products application, where the third file is the line items of the invoice.)

So you will want to create your keywords file and control editing access as you see fit, via scripting perhaps. Then in your titles file, make a portal with a relationship to the "join" file, and show keywords in a value list, or show them in a separate portal for selecting. Anyway. Now you can set up a portal in your keywords file, showing all the "join" records. Each keyword will display the title that it's linked to, and you can then go to the related title from there.

Did that make sense? I'm in a bit of a rush, sorry.

[Anders]

Hi Fitch

I think I'll have to digest that for a while.

When forcing this matter through my poor head earlier on, the best I could come up whith was two files. One for the titles etc and one for the keywords. In my web application I would then be able to use the keywords list to generate the search index to search the titles file. Well nothing is so easy that you can't complicate it, or however that saying goes in english.

And then there are portals

I'll just return to this forum and see if you or some other kind soul have posted more. And I'll browse around some more. Perhaps I can use the invoice/product analogy to actually find an answer alreade published here. I did try, but didn't know what ... keywords to use. No more smilies!

Cheers

[Fitch]

Back to the 2-file setup: make a text field ("Titles") in the keywords file, which would contain the name of each title, separated by returns ( ). So. Now you can GTRR (go to related record) based on this Titles field.

You can put titles into the field with a script. Let me know if you need help with that.

However, another thought: why do you have to have keywords? Why not just set up a Find that searches the actual text of the abstracts? Then you'd only need ONE file!

[Anders]

At this moment I'll just answer the last question. Why do I have to have keywords? Please stop reading if your don't want to know, it's quite a long and boring story

Keywords, subject headings, descriptors or what ever you may call them is a vital part when a librarian is indexing something.

Let me give you an example. Say that I where to index the following non existing database:

Title: Database of american presidents

Abstract: The following database describes all american presidents from George Washington up until today, and includes biographical information and a bibliography of all known books written by all the presidents.

Well which keywords would I use to describe this database? For instance, "Political history: USA", "Presidents: USA", "History: USA"

I may well have other databases "The history of the USA", "American who is who", "Politicians of the world" etc. All of these databases may (or may not) share one or several of the keywords whith the president-example. So if I search for "History: USA" I definitely want to find both "Database of american presidents" and the "The history of the USA" database. You can also see that searching for "History: USA" in the abstract is pointless.

Each abstract text will be copied from the databases own description of itself, and will not be created by me or my colleges. Thus we can't construct abstracs that blends with the keywords. Further more they would be quite unreadable. Since all of this will be made in swedish I unfortunately can't give you a real example (unless of course you speak swedish). And the abstract may well be in english, norwegian or what have we. But the keywords used will be swedish.

I really hope this explains why I want to use keywords. I will of course also have a regular search field. The problem with that is that people may well try to search for some word that isn't in either title, abstract or keywords. Lets return to my little example and say that someone tries to search for "presidenter" which is the swedish translation for "presidents"... 0.

An index of all available keywords gives people the opportunity to peek on what keywords are used in the database, and use them to search; instead of having to invent their own vocabulary. You will probably find several of the records in the database that way too, but I want to get rid of all possibilities of not finding anything/everything when you search the db the way it's designed to be searched.

Wow you got through all misspellings and well ...

Cheers

[Anders]

Rockn'roll!

I'm closing in on this one! I'll delete the short story originally posted in this reply.

I've managed to do this:

An input field and a script checks a second related field in a portal (if this is the correct terminology) if there is a match. If there is it just copies the portal info to the first empty repetition of a repeating field. To determine which is the first empty repetition of the repeating field I use a couple of sub-scripts (is that the correct english term?) with a bunch of GetRepetitions.

If there is no match it adds a new record in the 2nd db, and copies the info from the portal to the first empty repetition of ... well same as above.

I actually do beleive that I really have a good reason for using repeating fields. I want to make each instance of a repeating field into a clickable link on the search_results.htm, and be able to use it in a new search. So when for instance having found a record whith the keyword "Databases" I want to be able to click that word, and find all records whith "Databases" in one of the repetitions.

Something like this:

...FMPro?-db=whatever.fp3&-format=search_results.htm&...Keywords==Databases&...-find

I don't think I can accomplish that any other way.

Filling one field whith one keyword is OK, but if I use more than one all keywords will become one clickable link even if I use a . Of course I could also use a search this OR that OR that OR that OR that field. But ... no.

Having to constantly adding new repetitions is probably not an issue in this case. Too many keywords is bad keywords policy. A keyword in my book is one or two or maybe up to five words that really! describes whatever. If more than five words, well make a search all in the abstract instead. We'll give'em that possibility too.

There may be a portal way of doing all of this, but I have no idea how that may work.

Now I must just try to understand how I use a portal on the Web and interact with it through CDML. But I saw an interresting post in the CDML forum when passing it earlier on.

Thanks for all help. Any more suggestions? I really did use some of your tips. Fuzzy logic? Don't use repeating fields...so I did

Cheers

[ April 21, 2002, 12:45 PM: Message edited by: Anders Johansson ]