Encoding URIs in ISO 19139

Comments about the following proposals: http://marinemetadata.org/uriis:

Proposal 1:

  • [Tanya] Easy to accomodat within FGDC
  • [Yassine] Handle information about thesaurus and fragment
  • [Roy] better fit for ISO

Proposal 2:

  • [Dawn] Compact and efficient
  • [Roy] Simplicity

Additional comments:

  • Proposal 1 is not clear about separating the english label and the fragment. Leave the label for the GUI or the application dealing with it.

Proposal 3 was created in response to the comment. It is an expanded version of 1.

email trail leading up to this

From: "Lassoued, Yassine"
Date: October 31, 2007 2:41:07 AM PDT
To: Roy Lowry
Cc: ican_tech@lists.oregonstate.edu
Subject: Re: [ICAN_Tech] URI example

Dear all,
I totally agree with Roy on the fact that losing the English labels degrades
the utility of metadata. However, I believe that those labels (with French,
German, Spanish... labels) are part of the ontology. Using ontologies for
metadata does not mean only using the terms of the ontologies, but also
exploiting the relationships between those terms. Labels are particular
relationships defined as part of the ontologies and, to my point of view,
should remain as part of, and evolve with the ontologies. When you deliver
metadata, you should deliver the ontologies also, so that you allow the
applications to "understand" the semantics of your metadata and perform
reasoning. For these reasons I believe that what is part of the ontologies
should remain in the ontologies in order to facilitate maintenance.
Ontologies should be completely separate from metadata and linked only
through URIs. It is up to the application to link the ontologies with
metadata using those URIs and make best use of them (reasoning, multilingual
user-friendly interfaces, etc.).
Regards,
Yassine
-----------
From: "Roy Lowry"
Date: October 31, 2007 1:39:12 AM PDT
To:
Subject: Re: [ICAN_Tech] URI example

Dear All,

I won't be able to manage the telecon this afternoon. However, Yassine and Declan are visiting BODC tomorrow so we can discuss any issues raised. I'd totally missed the fact that examples 1&2 excluded English labels - glad somebody else is awake.

The current process is almost a carbon copy of the process we went through in SeaDataNet about 6 months or so back. Our discussion outcomes may be summarised as:

1) Machine readable references (URIs) to keywords is essential if applications are to link the metadata records to external semantic resources.

2) Human readable references (English labels) to keywords are highly desirable. The upside is that they allow documents to be checked and debugged using generic tools like text or XML editors. The downside is that the labels may become outdated if the semantic resource evolves. In SeaDataNet we have 40 partners covering a wide range of technical ability preparing metadata for ingestion into central systems. We also have strict semantic resource versioning. The upside therefore won the day. In all cases I think that if the English labels are lost then the utility of the documents is degraded.

3) A mapping should be maintained between English labels and URI fragments. That's why we ended up with the English label as keyword element content and the URI fragment as an attribute. Looking at example 3 I couldn't see how the URI fragment/label mapping worked, particularly as there were 1..n English labels, but only 1 URI fragment.

Cheers, Roy.

Luis Bermudez 10/30/2007 6:48 pm >>>
Dear All,

Ok, I see we are moving towards proposal 1. I created a new proposal
3, which is based on 1, but addresses the issue of the english labels
that Yassine brought up. The final question is if we want english
labels or not in the xml ?

Summary of comments here: http://workshop1.science.oregonstate.edu/uriso

Cheers,

-Luis

On Oct 30, 2007, at 6:01 AM, Roy Lowry wrote:

Hi Yassine,

Exactly the argument we went through in SeaDataNet. We started
with something along the lines of Option 2, and ended up with
something closer to Option 1 with the URI split from the resource
specification to reduce the amount of profiling required to map to
19115. I still prefer option 2 from a design fundamentals point of
view but can see that within the agreed standards framework option
1 is the better fit. That's life!

Cheers, Roy.

"Lassoued, Yassine" 10/30/2007 12:53 pm >>>
Dear all,
I've just had a look at luis' proposals and I think that both options
are fine. However, I am leaning towards option 1, which I think is
most
proper. The reason is that in option 1, we declare the URI once per
tag and provide all the necessary information about
the thesaurus (name, contact info, etc.) in the
tag.
Deriving the full URI of a keyword is quite easy as it only
consists of
the concatenation of the URI_Base and URI_Fragment. Also, with
option 1,
the application will be able to handle information about the thesaurus
(ontology).
Note that a may contain many keywords (
tag) which are not necessarily equivalent (e.g. temperature, pressure
and wind) but should belong to the same thesaurus and to the same
keywords type (e.g. theme).
For this reason, I think that using one tag for the
URI_fragment and another for the English_label will lead to a problem.
We'd better use only the URI_fragments. Labels can be managed at the
application level or the GUI.
Regards,
Yassine

WindSpeed

Temperature

Pressure

MIDA Themes

http://mida.ucc.ie/ont/20070830/theme.owl

2007-08-30

Spring
April

MIDA
Temporal

http://mida.ucc.ie/ont/20070825/temporal.owl

2007-08-25

-----Original Message-----
From: ican_tech-bounces@lists.oregonstate.edu
[mailto:ican_tech-bounces@lists.oregonstate.edu] On Behalf Of Roy
Lowry
Sent: 30 October 2007 11:32
To: ican_tech@lists.oregonstate.edu
Subject: Re: [ICAN_Tech] URI example

Hi Luis,

My personal opinion is that the less work an application has to do to
link a metadata vocabulary reference to its associated resource on the
semantic web the better, which leans me towards option two. Other
colleagues in SeaDataNet have other views, largely based on the
ease of
our migration from 19115 to 19139. If somebody (Declan?) can come up
with an ISO19139-compliant schema for option 2 then I would offer
it for
future adoption in SeaDataNet (probably at V2 level).

Cheers, Roy.

"Dunne, Declan" 10/29/2007 8:33 pm >>>
Hi all,

I am out out of office all this week except Wednesday. I got caught
with
another project deadline late last week. So thats why this end is
quiet.

Yassine, if you get a chance can you look over this on Tuesday, I can
discuss with you Wednesday

cheers
Declan

-----Original Message-----
From: ican_tech-bounces@lists.oregonstate.edu on behalf of Luis
Bermudez
Sent: Mon 29/10/2007 18:47
To: Deepsea Dawn
Cc: ican_tech@lists.oregonstate.edu
Subject: Re: [ICAN_Tech] URI example

Dear All,

This is just a reminder. Please look at the URI proposals so we can
discuss them the next meeting (this coming Wednesday).

http://marinemetadata.org/uriiso

Thank you Tanya and Dawn for your responses so far.

Cheers,

-Luis

___
Luis Bermudez Ph.D.
MMI Technical Lead - http://marinemetadata.org
bermudez@mbari.org - Office: (831) 775-1929 Mobile: (267) 481-4939
MBARI 7700 Sandholdt Road, Moss Landing CA 95039-9644, USA

On Oct 19, 2007, at 6:53 PM, Deepsea Dawn wrote:

On Oct 19, 2007, at 2:33 PM, Luis Bermudez wrote:

Sorry sent this too fast.

1) Looking at your XML and the XML sent by Duclan it appears that we
are looking at different ISO 19139 Schemas.
2) I found the TC211 schemas available here: http://
www.isotc211.org/

2005/gmd/
3) I wrote 2 proposals - maybe as a starting point about how to
encode URIs in CSW. Other groups are also interested in this issue,
so I put the documentation in the MMI web site (http://
marinemetadata.org/uriiso). Please comment ...

I'm just a lurker and an admirer from afar, but I like Proposal 2
because it seems more compact and efficient (and may still be
amenable to FGDC if most FGDCer are using the keyword field as they
should?)

Cheers,

Dawn

Post new comment

The content of this field is kept private and will not be shown publicly.
  • Allowed HTML tags: <a> <em> <strong> <cite> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Lines and paragraphs break automatically.

More information about formatting options