View unanswered posts | View active topics It is currently Mon May 27, 2019 10:01 am

All times are UTC + 10 hours [ DST ]

Reply to topic  [ 5 posts ] 
rif-cs:address element 
Author Message
ANDS Partners
User avatar

Joined: Fri Sep 03, 2010 4:46 pm
Posts: 9
What is the meaning of the rif-cs:address element?

You can have multiple addresses per location, so it's not the same thing as a physical place (or at least, multiple physical places are already able to be handled using multiple <location> elements).

You can have multiple child elements (electronic, physical) per address, so it's not the same thing as a postal address or an email address.

What actually is it for?

I am writing a UI for editing rif-cs documents, and I can't understand why one would want to create multiple address elements. It rather seems to me to be redundant. Can anyone suggest a use case for it?

Mon Apr 18, 2011 1:15 pm
ANDS Staff
User avatar

Joined: Wed Aug 18, 2010 3:56 pm
Posts: 3
Hi Con,

If I understand your question correctly, address is a wrapper element, containing physical and electronic address metadata. The text below is from the Schema Guidelines at: ... ml#address:

Element <address>
Wrapper element for physical and electronic address metadata.
May contain: physical | electronic
Contained within: location

Let me know if this does not answer your question.


Tue Apr 19, 2011 12:56 pm
ANDS Partners
User avatar

Joined: Fri Sep 03, 2010 4:46 pm
Posts: 9
Hi Julie

I do understand that address is a wrapper element. But that's just its syntactical function in the RIF-CS schema. What I don't understand is the MEANING of it (the semantics). The reason I want to know is that I'm writing a software application for editing RIF-CS, and hence I have to present some meaningful buttons and labels and so on to the end users. I want my user interface to be able to handle the full range of RIF-CS documents, but where I'm giving people options, I have to represent the options meaningfully.

The structure of this part of the RIF-CS schema looks like this:

location (repeatable)
address or spatial (repeatable)
physical or electronic (repeatable)

So if I have two electronic addresses for a given location, I could encode them in two ways, with (as far as I know) the exact same significance:

electronic 1
electronic 2


electronic 1
electronic 2

Should I give users a facility to create multiple <address> elements within a <location>, each containing a single <electronic> or <physical>, or should I just create a single <address> per <location>, but allow it to contain multiple <electronic> and <physical> elements? Either of these are valid, but is there any difference in meaning? I can't see that there is (the documentation doesn't give any), and this is why I think the <address> element may be purely redundant (i.e. it may be a purely "syntactical" construct with no semantics of its own).

Tue Apr 19, 2011 1:53 pm

Joined: Fri Oct 09, 2009 9:55 am
Posts: 57
Hi Con
I agree that the semantics of the location element need a bit more discussion. The problem you are facing, where there seems to be no semantically-based way to choose between different methods of encoding multiple addresses, suggests that the address element is redundant. It has no attributes of its own in RIF-CS. The location and address elements of RIF-CS are based on the ISO 2146 standard.
Each of the location elements
---electronic address
---physical address
---spatial location
relies on a different formatting standard for describing a location e.g. electronic based on URI, physical based on standards such as AS 4590, and spatial using one of the geospatial formats.

There has been some discussion about whether we need the spatial location capability at all, as it causes some confusion with the concept of spatial coverage: however, I think it allows people to provide location information in a format they may wish to use - maybe in the future GPS coordinates will be normally provided as part of addresses (I have seen some websites with this).

The RIF-CS Advisory Board will be considering and recommending changes to the RIF-CS schema, perhaps a review of the structure of the location element should be something for the Board to look at. The Board is being set up now and should be starting up soon. The problem with removing the address element, or any structural change to the schema, is of course that all existing feeds and systems that incorporate it would need to be changed, which would be a burden on all data providers.

I have double-checked with our programmers that how you encode multiple electronic or physical addresses into your system doesn't make any difference technically as long as the schema requirements are met, so it is really a judgement call for you. Personally I would go for repeating them at the lowest level, just to have the simplest and least repetitive structure, so I would include the multiples inside the address element rather than creating another address element for each repetition, but that is just a personal opinion, not an official ANDS policy.

Sally Goodenough
Australian National Data Service
W. K. Hancock Building (#43)
The Australian National University
Canberra, ACT, 0200, AUSTRALIA

P:+612 6125 1176
M: 0466 579 618

Thu May 05, 2011 11:19 am
ANDS Partners
User avatar

Joined: Fri Sep 03, 2010 4:46 pm
Posts: 9
Thanks very much, Sally. That's just what I needed to know.

Tue May 10, 2011 5:30 pm
Display posts from previous:  Sort by  
Reply to topic   [ 5 posts ] 

All times are UTC + 10 hours [ DST ]

Who is online

Users browsing this forum: No registered users and 1 guest

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software for PTF.