Wikivoyage:RDF Expedition Representation of Information Voyage Tips and guide

This page is no longer active and is retained for historical reference. Either the page is no longer relevant or consensus on its purpose has become unclear. Do not assume content on this page is still correct or up-to-date.

Contents

How could information be representated necessary for the aims declared in step 1?

Here we have to think about the RDF information itself: How could it be represented? What is an appropriate vocabulary? What vocabulary is already defined elsewhere? What do we have to define specialy for Wikivoyage? Find good definitions. Where should the information go? Maybe many more questions.

Step 2 is probaby the hardest one, except step 4. If you contribute here, you should have read RDF and Turtle RDF.

Try to find out what kind of information is needed for each goal listed in section #What Information for which goal (e.g. "Describing places"). Find a handy name for that kind of information (e.g. "placetype"). The only use of that name is that we can talk about. It needs not to be any kind of official. Add this name as a new subsection into section #Representing information. Describe it precisely in this subsection. Add the name of the information (i.e. "placetype" in our example) to the list of needed information below the header of the coresponding goal in section #What Information for which goal (i.e. "Describing places" in our example).

If you allready have an idea about an exact vocabulary that is defined somewhere, make a proposal in the corresponding subsection below #Representing information (i.e. "placetype" in our example).

Here is a list of wishes explained in step 1. The sequence has been changed in order to group related wishes. This list should be kept synchronous with the wishes of step 1. If you add some new wish, try to put it below an appropriate header or open a new one.

Here, we think about the information needed. Do not describe the wish itself again, this has to be done on the step 1 page. The aim of this section is to decide what kind of information is needed for each wish. Maybe, we find out here that some wishes are too complicated to realize.

Please sign with ~~~~ in the discussion part of each wish.

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

• placetype

Discussion:

Probably, no more info needed. -- (WT-en) Hansm 08:51, 22 Nov 2005 (EST)

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

• isnearby
• overlaps ?

Discussion:

Information needed:

• isPartOf

Discussion:

The subject might be part of more than one objects, but usually the object should be in the next higher hierarchical level.

Information needed:

Discussion:

Information needed:

• hasPart
• hasSupplement

Discussion:

Clustering is done from top to bottom. So, the top article has to define all its parts on the next lower hierarchical level. -- (WT-en) Hansm 14:02, 22 Nov 2005 (EST)

Information needed:

• indexAs
• dontIndex
• wildcardIndex
• useAlphabet
• omitInIndex

Discussion:

In printed versions, the index must point to the beginning of a topic. If the topic is an article, this is simply the beginning of the article, no matter where in the article the indexing information is given. But the topic may also be some place with no own article. In that case, it is important where in the article the indexing info stands. For example, the sphinx has no article for itself. So, the indexAs information must be put close to the point where the sphinx is described in an article of Gizeh. That means that indexes must be able to point to sections or subsections of articles.

Different spellings can be marked by several indexAs info. If the article's name should not be indexed (default is indexing), you can mark that with the dontIndex info. Using a combination of indexAs and dontIndex, you can change the index. For example, the article's name is "Scottish Highland", but it must be indexed simply as "Highland" since the adjective "scottish" doesn't make sense in a Scottland guide.

The wildcardIndex and omitInIndex info must be put into the country article or on a special contol page.

UseAlphabet is probably a wiki-wide controlpage that defines the alphabetical order for all indexes made in that wiki.

-- (WT-en) Hansm 14:46, 22 Nov 2005 (EST)

Information needed:

• printBefore
• printAfter
• dontPrint

Discussion:

Generaly, linearisazion should be done following the sequence in which articles of the same hierarchical level are listed in the higher lever article. For example, regions listed in the "Regions" section of a coutry article are printed in that order. Each region again defines the order of its subregions. The next region begins after the last subregion of the preceeding region.

PrintBefore and PrintAfter can be used to change that default order.

Is dontPrint necessary?

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Information needed:

Discussion:

Describes the kind of a place (not article). Possible values are: "country", "region", "hugecity", "bigcity", "smallcity", "district", "natpark", ...?

A predicate. Says that subject is part of object.

Defined by the Dublin Core: dcterms:isPartOf

Discussion:

Do subj. and obj. have to be places?

A predicate. Says that subject has object as part. S and O can be articles or sections of articles.

Defined by the Dublin Core.

Like hasPart, but optional. A phrasebook could be a supplement that some travellers don't need in their custom guide.

A symetrical predicate. Says that subject is nearby to object. Should by applied to places only.

A symetrical predicate. Says that subject and object overlap. Both, subj. and obj. should be regions.

Predicate. S is a string, O is an article or a section of an article.

The S is the text that shows up in the index, the O is where it points to.

Predicate. S is an article, needs no O.

Do not index the article's name.

Predicate. S and O are strings.

Provides info for an general redirect. S is redirected to O. For example, you can say: '"Om " wildcardIndex "Umm "' what means that all names starting with "Om " can be found in the index with "Umm " instead.

Probably not an RDF element. A list of characters or character combinations that defines an alphabetical order.

Predicate. S is a string, no O needed.

The string has to be omitted in indexed names. For example, El-Qalaa would show up in the index as Qalaa if you define '"El-" omitIndex'.

Predicate. S is an article, O is an article or pseudo-article that marks the begin of a sequence.

Defines the sequence in linearization for printed versions.

Predicate. S is an article, O is an article or pseudo-article that marks the end of a sequence.

Defines the sequence in linearization for printed versions.

Predicate. S is an article, no O needed.

Do not print that article at all.