OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

topicmaps-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xtm-wg] Binding Topics and Topic Characteristics to Time


I came across the question about dates and time intervals
too recently and
I have a quite simple solution in mind. I have not tried
this out thoroughly,
but I post it now, since the issue has been addressed now.

To avoid having to create topics for every date or time
interval,
PSIs could be used instead. If there was a well-defined
syntax for
generic date and time interval PSIs, topic map authors could
simply
use <subjectIndicatorRef> to refer to dates and time
intervals:

<topic id="petrograd">
  <baseName>
    <scope>
      <subjectIndicatorRef
       
xlink:href="http://www.topicmaps.org/psi-time-interval-01-01-1703-01-01-1913"/>
    </scope>
    <baseNameString>St. Petersburg</baseNameString>
  </baseName>
  <baseName>
    <scope>
      <subjectIndicatorRef
       
xlink:href="http://www.topicmaps.org/psi-time-interval-01-01-1991-today"/>
    </scope>
    <baseNameString>St. Petersburg</baseNameString>
  </baseName>
  <baseName>
    <scope>
      <subjectIndicatorRef
       
xlink:href="http://www.topicmaps.org/psi-time-interval-01-01-1914-01-01-1923"/>
    </scope>
    <baseNameString>Petrograd</baseNameString>
  </baseName>
  <baseName>
    <scope>
      <subjectIndicatorRef
        interval-01-01-1924-01-01-1990"/>
    </scope>
    <baseNameString>Leningrad</baseNameString>
  </baseName>
</topic>

(I do not know the correct dates, that's why I used Jan. 1st
in every example and there
 should of course be the possibility to simply refer to
years instead of dates...)

Question: Is there a better way to express that a certain
name characteristic assignment
          is valid in *either* scope A or scope B ?


Another example:

If I wanted to express when my birthday was, I'd try this:

<topic id="date"></topic>
<topic id="person"></topic>
<topic id="jan-algermissen"></topic>
<topic id="birthday-of"></topic>

<association>
  <instanceOf>
    <topicRef xlink:href="#birthday-of"/>
  </instanceOf>
  <member>
    <roleSpec>
      <topicRef xlink:href="#person"/>
    </roleSpec>
    <topicRef xlink:href="#jan-algermissen"/>
  </member>
  <member>
    <roleSpec>
      <topicRef xlink:href="#date"/>
    </roleSpec>
    <subjectIndicatorRef
     
xlink:href="http://www.topicmaps.org/psi-date-05-02-1971"/>
  </member>
</association>
 

Maybe, it is worth to consider such an approach for any
(physical)
unit (coordinates, lengths, weights,...).
Applications could simply parse the PSIs and represent the
value
(and unit) in a numeric form.
 
If these kinds of PSIs were defined by the XTM standard,
they would
serve as a point for application developers to agree on.




Jan







Eliot Kimber schrieb:
> 
> Steve Pepper and others have often posed the question: how do I express
> the fact that something in a topic map is scoped to a particular span or
> point in time without creating a topic for every instant in time I care
> about? For example, the city in Russia at 59 degrees 57' North latitude,
> 30 degrees 19' East longitude has been known as St. Petersburg,
> Petrograd and Lenningrad at various times. How does a topic map author
> express these time relationships and how does a topic map viewer use the
> time bindings?
> 
> I have worked out one possible solution that uses HyTime's scheduling
> facilities. The basic idea is to have scoping topics that are scheduled
> events in a time-based finite coordinate space (HyTime provides a
> mechanism for binding an axis of an FCS to real time). To bind a
> characteristic or topic to a particular span of time, you create a topic
> that is scheduled to that time and then put that topic in the
> characteristic's or topic's scope. A topic map viewer that understands
> the semantics of the FCS can provide the service of selecting "active"
> scopes based on their occurrence at a particular point in time or within
> some span of time. A topic map viewer that does not understand the FCS
> semantics just ignores that aspect of the data but still lets users
> select the time-bound scoping topics normally (as they would any other
> scoping topics). Topic map engines can also compare the extents of
> different topics to see if they are intersecting or disjoint, allowing
> answers to questions like "find all topics relevant to the year 1968" or
> "find all topics whose time span touches time span of this topic".
> 
> For example, with a time-aware topic map viewer, I could say "limit my
> view to topics and characteristics that are scheduled to the year 1920
> (that is, any topic whose scheduled extent includes any quanta in 1920).
> In the case of Lenningrad, that would limit the visible name
> characteristic to "Petrograd", the official name for St. Petersburg
> between 1914 and 1924.
> 
> Note that this approach is not specific to time--it could used to
> express any spatial relationships. For example, I could define a 2-axis
> FCS that represents a map with scheduled topics representing different
> countries or regions on that map. I could define a 3-axis FCS
> representing some physical place, like a building, with scheduled topics
> representing rooms.  I could define a 4-axis FCS representing a
> 4-variable data space with scheduled topics representing different
> interesting collections of data points within that space.
> 
> Here is a simple example using pidgin topic map syntax (I have not yet
> learned the XTM syntax, so this example reflects the original 13250
> syntax, more or less). This document does the following things:
> 
> 1. It sets up a HyTime finite coordinate space measured in real time, in
> units of years (that is, each quantum represents a single year),
> calibrated to One Common Era (1 A.D.).
> 
> 2. Creates an event schedule of scheduled topics that represent specific
> ranges of dates. These topics are created primarily to serve as scopes
> for other topics, but some also serve as topics that represent defined
> historical periods.
> 
> 3. Creates a topic for the city of St. Petersburg with three display
> names, each display name having a different time-based scope.
> 
> 4. Creates a topic Russian History, for scoping the discussion in
> general and the defined time periods in particular.
> 
> After the document I discuss how this document could be used by a topic
> map processor.
> 
> I have tried to make the HyTime-related markup as complete and correct
> as possible. The only thing I've elided is the marker function
> definition that provides a dynamic reference to the current time.
> 
> <!DOCTYPE SchedulingTopicMap [
>  <?IS10744 arch name="HyTime"
>       options="fcs evsched event extent dimlist"
>    ...
>  ?>
>  <!NOTATION datestring PUBLIC "A syntax for specifying time-based
> calibration of FCS axes" >
> ]>
> <SchedulingTopicMap HyTime="HyDoc">
>  <!-- The real-time-fcs element defines the "time-line" FCS. It is
> measured in years
>       and is calibrated to 1 C.E (1 A.D.), meaning that the first
> quantum represents
>       the year 1 Common Era.
>    -->
>  <real-time-fcs
>   id="common-era"
>   axes="realtime SIsecond"
>   realtime="3000 year"
>   calibrat="realtime timecalibrator datestring"
>   timecalibrator="1CE"
>   HyTime="fcs"
>  />
>  <!-- The TopicSchedule element is a HyTime event schedule that
>       contains those topics that are bound to specific regions
>       of the time line.
>    -->
>  <TopicSchedule
>    fcs="common-era"
>    HyTime="evsched"
>  >
>  <!-- This is a topic that is also a HyTime event
>       (Note that I am ignoring the fact that in 13250
>       topics are mapped to varlink--I think that's bogus
>       and is incovenient here, so I'm ignoring it for
>       the purpose of this discussion.) Another solution
>       would be to add a wrapper event element around
>       topic, but I think that extra syntax is unnecessary.
>    -->
>  <topic id="daterange-1703-1913"
>    exspec="ex01"
>    HyTime="event"
>  >
>   <!-- The extent element binds the topic to a region on the FCS,
>        in this case, from the year 1703 to the year 1913 (start, length)
>     -->
>   <extent id="ex01">1703 210</extent>
>  </topic>
>  <topic id="daterange-1914-1923"
>    exspec="ex02"
>    HyTime="event"
>  >
>   <extent id="ex02">1914 9</extent>
>  </topic>
>  <topic id="daterange-1924-1990"
>    exspec="ex03"
>    HyTime="event"
>  >
>   <extent id="ex03">1924 66</extent>
>  </topic>
>  <topic id="daterange-1991-present"
>    exspec="ex04"
>    HyTime="event"
>  >
>   <!-- Here the markfun element is a marker function that is calculating
>        the number of years since 1991 at the current time. It's result
>        is a single integer that is used as the second axis marker.
>     -->
>   <extent id="ex04">1991 <markfun>$current-time -
> 1991</markfun></extent>
>  </topic>
>  <topic id="Kievan-Appanage-period" scope="russian-history"
>    exspec="ex05"
>  >
>   <basename>Kievan-Appanage period</basename>
>   <extent id="ex05">860 829</extent>
>  </topic>
>  <topic id="Imperial-period" scope="russian-history"
>    exspec="ex06"
>  >
>   <basename>Imperial period</basename>
>   <extent id="ex06">1689 227</extent>
>  </topic>
>  <topic id="Soviet-period" scope="russian-history"
>    exspec="ex07"
>  >
>   <basename>Soviet period</basename>
>   <extent id="ex07">1917 74</extent>
>  </topic>
>  <topic id="Post-Soviet-period" scope="russian-history"
>    exspec="ex08"
>  >
>   <basename>Post-Soviet period</basename>
>   <extent id="ex08">1991 -1</extent>
>  </topic>
>  </TopicSchedule>
>  <!-- The following topic represents the city of St. Petersburg.
>       It is scoped both to "city" and to the periods of Russian history
>       during which the city existed.
>    -->
>  <topic
>    id="petrograd"
>    scope="Imperial-period Soviet-period Post-Soviet-period city"
>  >
>   <basename>petrograd</basename>
>   <!-- The display names are each scoped to the date ranges during
>        which the name was the official name of the city.
>     -->
>   <dispname scope="daterange-1703-1913 daterange-1991-present">St.
> Petersburg</dispname>
>   <dispname scope="daterange-1914-1923">Petrograd</dispname>
>   <dispname scope="daterange-1924-1990">Lenningrad</dispname>
>  </topic>
>  <topic id="russian-history">
>   <basename>Russia, history of</basename>
>  </topic>
>  <topic id="city">
>   <basename>city</basename>
>  </topic>
> </SchedulingTopicMap>
> 
> Note that from a pure topic map perspecitive, there is nothing special
> about this map--there are topics and scopes and everything is completely
> sensible. The fact that some of the topics are also HyTime events causes
> no interference with topic map semantics or syntax--a topic map
> processor simply ignores the HyTime-specific stuff, just as it would
> ignore any other non-topic-map stuff.
> 
> However, because the scheduling information is there, an enhanced topic
> map engine could take advantage of that information by providing
> features that let users select the active viewing scope in terms of
> dates.
> 
> For example, I should be able to say "I am interested in Russian History
> topics relevant to 1927". The system will select the scoping topic
> "Russian History" and those scheduled topics whose extent includes the
> year 1927, which in this case is the topics "daterange-1924-1990" and
> "Soviet-period". This has the effect of limiting the displayed name for
> the topic "petrograd" to "Lenningrad".
> 
> I can also ask the question "Is the topic 'petrograd' relevant to the
> year 1689?" The answer is yes because one of its scoping topics has 1689
> in its scope (the topic "Imperial-period"). I gave the topic this scope
> because its existence started during the Imperial period.
> 
> But this is probably an authoring mistake. It would probably be better
> to create a new scheduled topic that is the extent of the city's
> existence and use that as the scope, so I'll change the petrograd topic
> to this:
> 
>  <topic
>    id="petrograd"
>    scope="existence-of-petrograd city"
>  >
>   <basename>petrograd</basename>
>   <!-- The display names are each scoped to the date ranges during
>        which the name was the official name of the city.
>     -->
>   <dispname scope="daterange-1703-1913 daterange-1991-present">St.
> Petersburg</dispname>
>   <dispname scope="daterange-1914-1923">Petrograd</dispname>
>   <dispname scope="daterange-1924-1990">Lenningrad</dispname>
>  </topic>
> 
> And create this new scheduled topic (within the TopicSchedule):
> 
>  <topic id="existence-of-petrograd"
>    exspec="ex09"
>  >
>   <basename>from founding of petrograd to now</basename>
>   <extent id="ex09">1703 <markfun>$current-time -
> 1703</markfun></extent>
>  </topic>
> 
> Now when I ask the question "Is 'petrograd' relevant to 1689?" the
> answer is "no".
> 
> But I can also ask questions about the relative time relationships of
> topics and the things they scope. For example, I can learn that St.
> Petersburg existed during the Imperial period by asking the question:
> "What topics have in their scope topics whose scheduled extent overlaps
> the scheduled extent of the topic 'Imperial-period'?". This returns the
> petrograd topic with the display name St. Petersburg visible because the
> petrograd topic's scoping topic of "existence-of-petrograd" is a
> scheduled topic that overlaps the extent of the Imperial period topic,
> as does the scoping topic for the display name St. Petersburg.
> 
> Note that all the time-specific processing is done by the topic map
> engine as additional features over and above the base features required
> by the topic map standard. The use of the scheduling stuff does not
> impair interchange as long as we presume that processors can ignore
> stuff they don't recognize. Because the time-based stuff is in terms of
> a standard, there is some hope of consistent interpretation by different
> topic map processors.
> 
> Note also that the additional syntax needed to create the date ranges is
> minimal. It is a little more verbose than absolutely necessary in the
> abstract because the HyTime standard requires extent specifications to
> be subelements of events--there's no way to put the extent specification
> in an attribute of the event itself. But the scheduled topics probably
> have more value as topics than I've given them in this example (I was
> trying to keep the example as simple as possible).
> 
> Cheers,
> 
> Eliot
> 
> 
> To Post a message, send it to:   xtm-wg@eGroups.com
> 
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
> 
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

-- 
Jan Algermissen
Chief Programmer


SERUBA GmbH
Notkestrasse 13
22607 Hamburg
Germany

Tel: ++49 (0)40 41 360-211
Fax: ++49 (0)40 41 360-100

jalgermissen@seruba.com
http://www.seruba.com

------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Find software faster. Search more than 20,000
software solutions on KnowledgeStorm. Register
now and get started.
http://us.click.yahoo.com/ee3V2C/RNSCAA/2h4EAA/2n6YlB/TM
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC