use of temporalData

Ashok Hariharan

unread,

Oct 17, 2011, 2:44:30 AM10/17/11

to akomant...@googlegroups.com

I have a case where I am recording metadata about a parliament as a
AN document.

so the parliament has "election date" and "dissolution date" --

What is the best way to capture the metadata for these dates ?

Until now i have been doing this --

method #1

(where #ElectionDate and #DissolutionDate are TLCConcept elements )

But what if i want to use temporalGroup -- is the following correct ?
(is it still fine to use method #1 ? )

method #2

There is also the case when the parliament is ongoing -- so there is
no end-date yet -- in that case is using <temporalData> relevant
..since the duration is not known yet ?

Finally what is the criteria for having a "temporalGroup" -- i mean
what kind of periodic dates should i be grouping together ?

Fabio Vitali

unread,

Oct 17, 2011, 4:13:19 AM10/17/11

to akomant...@googlegroups.com

Dear Ashok,

Il giorno 17/ott/2011, alle ore 08.44, Ashok Hariharan ha scritto:

> I have a case where I am recording metadata about a parliament as a
> AN document.
>
> so the parliament has "election date" and "dissolution date" --

First of all, in Akoma Ntoso dates in the body regards dates IN the document, and dates in the metadata regards date OF the document. Dates non mentioned in the document about facts, entities or people do not belong to the document nor the metadata. Therefore, I am assuming that your document contains some dates that regard the Parliament. Otherwise, it is not the body, nor the metadata the place to specify them.

> What is the best way to capture the metadata for these dates ?
>
> Until now i have been doing this --
>
> method #1
>
> <docDate date= "2001-01-31" refersTo= "#ElectionDate">2001-01-31</docDate>
> <docDate date= "2006-04-02" refersTo= "#DissolutionDate">2006-04-02</docDate>
> (where #ElectionDate and #DissolutionDate are TLCConcept elements )

docDate, as the name implies is one of the dates of the DOCUMENT. The election or the dissolution of a Parliament is NOT a date of the document. Therefore, and by all means, docDate is not the right solution.

If, in the ORIGINAL version of the document, you find a mention to the Election and Dissolution date of a legislature of the Parliament, then we should find a method that uses <date> and not <docDate>, because, as I mentioned, these dates do not apply to the document. Therefore, the following could be a solution:

"the XXV Legislature was elected on the <date date= "2001-01-31" refersTo= "#ElectionDate">31st of March, 2001 [or whatever the exact wording in the ORIGINAL document was]</date>."

> But what if i want to use temporalGroup -- is the following correct ?
> (is it still fine to use method #1 ? )
>
> method #2
>
> <temporalData ...>
> <temporalGroup id="p1">
> <timeInterval start="#election-date" end="#dissolution-date"
> refersTo="#inforce"/>
> </temporalGroup>
> </temporalData>
> <lifecycle source="#fv">
> <eventRef id="election-date" date="2001-01-31" source="#ro1"
> type="generation" refersTo="#LegislativeCreation"/>
> <eventRef id="dissolution-date" date="2006-04-02" source="#rp1"
> type="modification" refersTo="#LegislativeModification"/>
> </lifecycle>

Lifecycle refers to events of the document. Workflow refers to steps in a sequence of steps (a workflow) affecting a document. It seems to me that in this case workflow is more relevant than lifecycle for what you are trying to do, but still this surprises me a lot. Akoma Ntoso deals with documents and not abstract concepts (legislatures) or concrete entities (Parliaments). As long as, for THIS SPECIFIC DOCUMENT, the start date and end date of a related concept (legislature) for a related entity (Parliament) are relevant, by all means specify them (as well as ALL THE OTHER relevant steps) in the workflow of the document.

This could be a solution, but I am not sure it meets your desires... The point is that Akoma Ntoso is NOT made to describe facts about entities and organizations, but only to describe facts about the documents. Also, do NOT mix Parliaments with legislatures. The election does not create a new parliament, this is just a figure of speech. Revolutions create Parliaments. Election mark the beginning and end of Legislatures of a Parliament. Also, I do not believe that elections per se mark the endpoints of Legislatures, but there must be some official steps declaring the results of the election and the official beginning of the legislature.

> There is also the case when the parliament is ongoing -- so there is
> no end-date yet -- in that case is using <temporalData> relevant
> ..since the duration is not known yet ?

Element timeInterval can contain the start attribute only, without problems.

> Finally what is the criteria for having a "temporalGroup" -- i mean
> what kind of periodic dates should i be grouping together ?

As I said, temporalGroup regards dates of the document. Using it for dates of related concepts is a big stretch. No problems if you do, but still... hard to find a good match. Anyway, since temporalGroup is in the metadata and authored through the source attribute, you can put in there any group of dates you feel are needed. Only point is, every fragment in the document can point to at most ONE temporalGroup, so you should create temporal groups that capture all the relevant dates of a fragment.

Finally, let me remind you NEVER to use #bungeni as the source of metadata, as Bungeni is a software, and the source needs to be an Actor, i.e., either a TLCPerson or a TLCOrganization responsible for the specific choice of metadata values, something that Bungeni does not and should not do.

Ciao

Fabio

>
> --
> You received this message because you are subscribed to the Google Groups "akomantoso-xml" group.
> To post to this group, send email to akomant...@googlegroups.com.
> To unsubscribe from this group, send email to akomantoso-xm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/akomantoso-xml?hl=en.
>

--

Fabio Vitali Tiger got to hunt, bird got to fly,
Dept. of Computer Science Man got to sit and wonder "Why, why, why?'
Univ. of Bologna ITALY Tiger got to sleep, bird got to land,
phone: +39 051 2094872 Man got to tell himself he understand.
e-mail: fa...@cs.unibo.it Kurt Vonnegut (1922-2007), "Cat's cradle"
http://vitali.web.cs.unibo.it/

Ashok Hariharan

unread,

Oct 17, 2011, 4:51:40 AM10/17/11

to akomant...@googlegroups.com

On Mon, Oct 17, 2011 at 11:13 AM, Fabio Vitali <fa...@cs.unibo.it> wrote:
>> method #2
>>
>> <temporalData ...>
>> <temporalGroup id="p1">
>> <timeInterval start="#election-date" end="#dissolution-date"
>> refersTo="#inforce"/>
>> </temporalGroup>
>> </temporalData>
>> <lifecycle source="#fv">
>> <eventRef id="election-date" date="2001-01-31" source="#ro1"
>> type="generation" refersTo="#LegislativeCreation"/>
>> <eventRef id="dissolution-date" date="2006-04-02" source="#rp1"
>> type="modification" refersTo="#LegislativeModification"/>
>> </lifecycle>
>

> This could be a solution, but I am not sure it meets your desires... The point is that Akoma Ntoso is NOT made to describe facts about entities and organizations, but only to describe facts about the documents. Also, do NOT mix Parliaments with legislatures. The election does not create a new parliament, this is just a figure of speech. Revolutions create Parliaments. Election mark the beginning and end of Legislatures of a Parliament. Also, I do not believe that elections per se mark the endpoints of Legislatures, but there must be some official steps declaring the results of the election and the official beginning of the legislature.
>

I think the below suggestion would be most appropriate -- we dont
really have a "document" per se for the legislature -- this is just
metadata about the legislature which I want to capture as a Akoma
Ntoso document -- so there is no real "print document" for it with
visual dates and titles -- i.e. the rendering is virtual ,
arbitrary...which i think makes using the temporalData more
appropiate. OK -- it did go through a 'creation workflow' in the
system but that setup a "virtual parliament" in the system.

Flavio Zeni

unread,

Oct 17, 2011, 5:36:30 AM10/17/11

to akomant...@googlegroups.com

Let me explain a bit the "context". In order to allow maximum flexibility to parliaments that will use Bungeni and also having in mind the the long term preservation of parliamentary information (not just documents), the public face of Bungeni will be entirely based on XML documents delivered through an XML framework that supports business logic and styling.

So, we may be "stretching" or may be "abusing" Akoma Ntoso that was not meant to really cover all the needs we have e.g. a metadata of a parliament, or description of a committee et. et. but since we use Akoma Ntoso for the actual documents that Akoma supports ... hope it will be consider a minor "crime".

Flavio

Fabio Vitali

unread,

Oct 17, 2011, 8:36:56 AM10/17/11

to akomant...@googlegroups.com

I see. I am only wondering why using Akoma Ntoso at all. Why don't you define your own XML format for your own purposes? In fact, at least part of such public face should be the connecting ontology between Akoma Ntoso document collections and inference engines, so there are ways to make them better than others.

I have ideas and I could help.

Ciao

Fabio

--

Ashok Hariharan

unread,

Oct 17, 2011, 10:24:49 AM10/17/11

to akomant...@googlegroups.com

On Mon, Oct 17, 2011 at 3:36 PM, Fabio Vitali <fa...@cs.unibo.it> wrote:

I see. I am only wondering why using Akoma Ntoso at all. Why don't you define your own XML format for your own purposes?

Actually thats a question i have asked myself ...

In fact, at least part of such public face should be the connecting ontology between Akoma Ntoso document collections and inference engines, so there are ways to make them better than others.

I would be happy to know your views on this -- because we do have such a scenario / requirement see attached

1) "bungeni-output-parliament-metadata.xml"
2) "an-bungeni-output-parliament-metadata.xml"

1) ==> is the transformed output of bungeni metadata (its not the default output of the system , its transformed and restructured from the original ... )

2) ==> is the AN output produced from (1)

Now - for query / retrieval and presentation purposes the format in (1) is to me much easier to work with (and it can be made even easier) , since it doesnt have much in-directional or semnatically informative metadata (like AN has ). Also we have some application specific rules (based on permissions which decide which info is visible to which user )

While (2) is also important since thats the long term archival /persistence format. I say AN is also relevant here -- because other documents like bills, acts , debates will be in AN for sharing with the public and other institutions.

The same process generates both (1) and (2) -- and I use (1) for retrieval and presentation and (2) for sharing and archival ...

What do you think ?

an-bungeni-output-parliament-metadata.xml

bungeni-output-parliament-metadata.xml

Fabio Vitali

unread,

Oct 18, 2011, 7:08:31 PM10/18/11

to akomant...@googlegroups.com

Dear Ashok,

there are several things I introduced in the answer that require some explanation.

First of all, as planned, I created a very simple XML document. It is one of those XML examples that need no DTD or grammar, but some basic understanding of the underlying organization. It needs no grammar, because I expect that producers and consumers are the same thing, i.e., the same software, so there is no need for a contract between independent parties as it would if producers and consumers were different.

Second, I am allergic to opaque codes, i.e. numbers or overly generic labels. So in your example, <field name="parliament_id">2</field> makes me wonder why not using a more readable and intuitive value. That's why in my example all ids are explicit and usually sided with a showAs attribute.

Third, I tried, as much as possible and for no better reason than the fact that is was possible and easy, to map the document to the underlying Akoma Ntoso ontology. This means, basically, that although I understand that the example you sent was meant mainly as a parameter file for the Bungeni startup, it could be expanded to include facts and connectors between the ontological statements placed within the actual Akoma Ntoso documents and some underlying database containing facts and useful background information (such as, for instance, a list of all MPs of a parliament, a list of all document types, ministries, neighboring states, provinces, and all the information that is necessary to understand a parliamentary document yet is not included in the document itself).

Fourth, I organized the XML document is structures of arbitrary order that collect and cluster values and properties associated to specific concepts. So for instance, I separated values about Bungeni per se (e.g., the version number or the language or the permissions) to values about concepts that are APPROPRIATE TO the Bungeni editor but are not OF THE Bungeni editor. Thus for instance the election date matters for the legislature, and not for the editor itself. This process can and should be repeated for any value you feel like storing in this document.

So the structure of the XML file is as follows: there is a root (called, more for affection than for any other reason) <ontology>. Within the root, there are as many containers as there are concepts that you feel like describing. Each container is a subclass of a specific TLC class of the Akoma Ntoso ontology, but again this is more for affection than for any other reason. Each container also has a showAs for those moments, in three months, you will not be able to remember what this concept is for. Containers with the same name can be repeated (see <group>) and may appear in any order. Within each containers there are properties associated to the container itself. There is no fixed list of properties, and you can add your own, following the same idea as the others.

Every property follows the same conceptual form: CONCEPT hasPROPERTY VALUE, where CONCEPT is the concept specified by the container, PROPERTY is the name of the property specified by the element within the container, and VALUE is the datum placed within the value attribute of the property element. For instance:

can be read as follows: the legislature called "XIV legislature" has election "2011-02-01", which is a date according to the relevant XML Schema datatype. This allow an easy and immediate translation into RDF for semantic inferences on the values, if and when needed. Remember that the concept is the subject, the property is a has* verb, and the value is either an XSD datatype or a reference to another concept described there or somewhere else with the href property. For instance:

<editor id="bungeniEditor" showAs="Bungeni Editor" isA="TLCObject">
<status>active</status>
<version key="true" type="xsd:integer">2</version>
<build type="xsd:date">2011-10-07T14:58:20</build>
<language>en</language>
<permissions href="#p1"/>
<principalGroup href="#group.parliament.2"/>
</editor>

can be read as follows: the editor called "Bungeni Editor" has status "active", has version "2" (an integer), has build "2011-10-07T14:58:20" (a date), has language "en", has permissions specified by the concept whose id is "p1" and has a principal group whose id is "group.parliament.2".

The attributes id, isA and key I added again for potential integration with the Akoma Ntoso ontology. As you may remember, an ontological URI in Akoam Ntoso is composed of two required parts, the Top Level Class (TLC) the entity belongs to, and its unique id. In between these two, one can add as many specifiers as desired, to help in describing and identifying the concept. So for instance, the URI /ontology/person/John.Smith65 is a complete URI for the entity of class "TLCPerson" and whose id is "John.Smith65". But the URI /ontology/person/kenyan/judge/John.Smith65 still refers to exactly the same entity, but tells you in addition that this guy is kenyan and a judge. This creates implicit property-based subclasses of the relevant TLC class.

In pure OWL, classes are defined by the mere listing of its members, and so you can have a class composed of John Smith, my leg, fantasy, and 35 cents. Owl classes are nothing more and nothing less than sets. Good practice, and specific syntactic improvements in OWL 2, suggests to specify classes as restrictions of superclasses (up to owl:thing) based on the restriction of the allowed values. For instance, it is a good practice to define Kenyan Judges as those person whose property "job" is "judge" and whose property "nationality" is Kenya, as follows:

Class: KenyanJudge
SubClassOf: TLCPerson
EquivalentTo: hasJob value "judge" and hasNationality value "Kenya"

Since a Kenyan Judge is a kenyan that is a judge as well as a judge that is a Kenyan, you could write both

/ontology/person/kenyan/judge/John.Smith65
/ontology/person/judge/kenyan/John.Smith65

always referring to the same person.

The property that you may want to use as intermediate steps in URI are keys in the full explication of the ontology and are those that have the key="true" attribute in the relevant property.

I hope this was clear enough and that you can use what I wrote and extend it according to needs.

Ciao

Fabio

--

> <an-bungeni-output-parliament-metadata.xml><bungeni-output-parliament-metadata.xml>

bungeni-metadata.xml

Ashok Hariharan

unread,

Oct 24, 2011, 8:56:35 AM10/24/11

to akomant...@googlegroups.com

Hi Fabio --

On Wed, Oct 19, 2011 at 2:08 AM, Fabio Vitali <fa...@cs.unibo.it> wrote:

First of all, as planned, I created a very simple XML document. It is one of those XML examples that need no DTD or grammar, but some basic understanding of the underlying organization. It needs no grammar, because I expect that producers and consumers are the same thing, i.e., the same software, so there is no need for a contract between independent parties as it would if producers and consumers were different.

Second, I am allergic to opaque codes, i.e. numbers or overly generic labels. So in your example, <field name="parliament_id">2</field> makes me wonder why not using a more readable and intuitive value. That's why in my example all ids are explicit and usually sided with a showAs attribute.

Agreed ...

Third, I tried, as much as possible and for no better reason than the fact that is was possible and easy, to map the document to the underlying Akoma Ntoso ontology. This means, basically, that although I understand that the example you sent was meant mainly as a parameter file for the Bungeni startup, it could be expanded to include facts and connectors between the ontological statements placed within the actual Akoma Ntoso documents and some underlying database containing facts and useful background information (such as, for instance, a list of all MPs of a parliament, a list of all document types, ministries, neighboring states, provinces, and all the information that is necessary to understand a parliamentary document yet is not included in the document itself).

I see the benefit of doing this after reviewing your format ...

About the below and the proposed methodology -- i have one question -- how do we represent associative relationships here ?

e.g. a question assigned to a committee

or a question assigned to a ministry

or a user member of a committee (or committees ) - basically a user with memberships.

Something like ?

</question>

The group definition itself is in a different xml document (similarly with the memberships )

Ashok Hariharan

unread,

Oct 24, 2011, 9:08:35 AM10/24/11

to akomant...@googlegroups.com

Let me explain my question better --

The example i sent you and the format you sent back to me represent a legislative organization : parliament

This parliament is also referenced in other documents -- e.g. a document describing a committee or a document describing a member of parliament.

How do i cross reference ? Bungeni generates IDs which are unique for a type of object -- e.g. a parliament object with ID 1 and electionDate X is different from parliament object with ID 2 and electionDate Y ... so i could use that formula to generate "pseudo uri" and use that for cross references ?

Ashok

Fabio Vitali

unread,

Oct 30, 2011, 1:02:32 PM10/30/11

to akomant...@googlegroups.com

Dear Ashok,

I'll try to provide an answer. I am not sure it is the best answer, but it is the best I have so far.

Il giorno 24/ott/2011, alle ore 15.08, Ashok Hariharan ha scritto:

> Let me explain my question better --
>
> The example i sent you and the format you sent back to me represent a legislative organization : parliament
>
> This parliament is also referenced in other documents -- e.g. a document describing a committee or a document describing a member of parliament.
>
> How do i cross reference ? Bungeni generates IDs which are unique for a type of object -- e.g. a parliament object with ID 1 and electionDate X is different from parliament object with ID 2 and electionDate Y ... so i could use that formula to generate "pseudo uri" and use that for cross references ?

Please remember: a Parliament is a timeless entity. A legislature is a period of time in which the parliament is filled with a given selection of MPs for a given period of time. So what you are referring at is either two different legislatures for the same parliament, or two legislatures of two different parliaments. That's quite different.

So every entity you want to make a reference to must

a) be an instance of a (subclass of) one of the Akoma Ntoso Top Level Classes
AND
b) have an URI according to the Akoma Ntoso Naming Convention for ontological entities (sections 8.7 and 8.8 of the Release Notes).

Please consider them URI and not simple IDs. This means that they DO have a specific ID, but they must be referenced with their full URI according to the Akoma Ntoso naming convention, i.e. /ontology/[TLCClass]/[subclass1]/[subclass2]/.../[specificID].

Their URI is what you need to use as the href value of references. You should not use "pseudo URI", you should use real, serious, concrete, full scale URIs according to the AN Naming Convention.

>
> Ashok
>
>
> On Mon, Oct 24, 2011 at 3:56 PM, Ashok Hariharan <as...@parliaments.info> wrote:
> Hi Fabio --
>
>
>> On Wed, Oct 19, 2011 at 2:08 AM, Fabio Vitali <fa...@cs.unibo.it> wrote:
>> First of all, as planned, I created a very simple XML document. It is one of those XML examples that need no DTD or grammar, but some basic understanding of the underlying organization. It needs no grammar, because I expect that producers and consumers are the same thing, i.e., the same software, so there is no need for a contract between independent parties as it would if producers and consumers were different.
>>
>> Second, I am allergic to opaque codes, i.e. numbers or overly generic labels. So in your example, <field name="parliament_id">2</field> makes me wonder why not using a more readable and intuitive value. That's why in my example all ids are explicit and usually sided with a showAs attribute.
>>
>
>
> Agreed ...
>
>> Third, I tried, as much as possible and for no better reason than the fact that is was possible and easy, to map the document to the underlying Akoma Ntoso ontology. This means, basically, that although I understand that the example you sent was meant mainly as a parameter file for the Bungeni startup, it could be expanded to include facts and connectors between the ontological statements placed within the actual Akoma Ntoso documents and some underlying database containing facts and useful background information (such as, for instance, a list of all MPs of a parliament, a list of all document types, ministries, neighboring states, provinces, and all the information that is necessary to understand a parliamentary document yet is not included in the document itself).
>>
>
> I see the benefit of doing this after reviewing your format ...
>
> About the below and the proposed methodology -- i have one question -- how do we represent associative relationships here ?
>
> e.g. a question assigned to a committee
> or a question assigned to a ministry
> or a user member of a committee (or committees ) - basically a user with memberships.
>
> Something like ?
>
>
> <question ...>
>
> <assignedTo href="URI to group" isA="TLCReference" />
>
> <assignedTo href="URI to committee" isA="TLCReference" />
>
> </question>
>
> The group definition itself is in a different xml document (similarly with the memberships )

Attribute isA should be used for the definition of entities. All Properties are references, so there is no need to specify them as such. But entities can belong to any class, and therefore you should specify at least the TLC it belongs to. So you example is:

I hope this answers some doubts.

Ciao

Fabio

Reply all

Reply to author

Forward