From seaman at noao.edu Wed Jun 1 08:32:36 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 1 Jun 2005 08:32:36 -0700 Subject: UCDs vs ontologies? In-Reply-To: <429DBE0C.7060905@cea.fr> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: On Jun 1, 2005, at 6:54 AM, Pierre Didelon wrote: > But do/must UCD be the solution to (all?) natural langage parsing? It would be premature to begin the work of the board by willy-nilly reassigning identifiers such as "em". It seems likely that we will need to be able to express the concepts of both "electromagnetism" and "emission". If there is emission, there is absorption. And sometimes we may want to express the combination of "electromagnetic emission" at the same time. On the other hand, we're told that the role of UCDs is distinct from that of ontologies. An ontology is an (attempt) at expressing the complete range of some knowledge domain. Astronomy is a big subject - its ontology will be big. Perhaps by analogy we can view an ontology as the unabridged dictionary for some subject, whereas UCDs are simply one way to build a glossary for a specific purpose. Glossaries are often small enough to be appended to a brief document. Personally, I think the VO community will need to develop several separate ontologies over time as well as several separate glossaries of UCDs or UCD-like constructs. It is not obvious that a glossary of UCDs for tabular convenience is equivalent to a glossary of UCDs for VOEvent convenience. An ontology can afford to be large and unwieldy to reach its goal of being complete and accurate. A UCD style glossary, on the other hand, will eventually reach an optimum size. Its utility will pass a point of diminishing returns. Too much precision engenders confusion. The availability of too many options results in overlapping shades of meaning. I gather the current list of UCDs was generated by looking at actual tables in the literature. This is just how the unabridged OED was created from words sieved from millions of quotations. Just like a dictionary, the work of maintaining the list of UCDs will continue indefinitely as new tabular usage is coined. I would suggest that the creation of this new list of UCD-like entities to describe astronomical "concepts" is fundamentally a different exercise. We may not be trying to generate a complete ontology with all interrelationships clearly drawn between all concepts, but we are trying to be complete in the sense of not leaving any gaps in the web of concepts. "Star" and "galaxy" will clearly make the final cut. "Star.white_dwarf" and "galaxy.spiral" most likely, too. But it won't take many levels to exhaust the utility of compiling such a list. I expect the final list to have hundreds of entries, not tens of thousands. One final point. The nature of this board is to participate in the process of certifying an official list of terms. I think the true utility of both glossaries and dictionaries will be achieved when facilities are available for creating and maintaining *unofficial* lists. For VOEvent, for instance, it seems likely that each project publishing events will adopt its own glossary pertinent to its own instrumentation and observations. We should support these activities and provide a framework for project specific glossaries. They will spring into existence whether or not we do so. At least if we support the creation of project specific glossaries, we can have some say in controlling a common semantic structure and a standardized distribution mechanism. This might also naturally lead to the next step of layering UCD glossaries on top of our emerging ontology (ies). A glossary, after all, is nothing but a well chosen list of words out of the dictionary. It is the dictionary that provides etymology, synonyms and antonyms, classification by part of speech, tenses and gender, pronunciation, ... Sorry for the cross-posting. If we can't restrain ourselves from generating all these mailing lists, I'm not sure what hope we have for a coherent set of UCD lists :-) Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From eca at mssl.ucl.ac.uk Wed Jun 1 08:42:25 2005 From: eca at mssl.ucl.ac.uk (Elizabeth Auden) Date: Wed, 1 Jun 2005 16:42:25 +0100 (BST) Subject: UCDs vs ontologies? In-Reply-To: References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: > On the other hand, we're told that the role of UCDs is distinct from that of > ontologies. An ontology is an (attempt) at expressing the complete range of > some knowledge domain. Astronomy is a big subject - its ontology will be > big. > Personally, I think the VO community will need to develop several separate > ontologies over time as well as several separate glossaries of UCDs or > UCD-like constructs. It is not obvious that a glossary of UCDs for tabular > convenience is equivalent to a glossary of UCDs for VOEvent convenience. An > ontology can afford to be large and unwieldy to reach its goal of being > complete and accurate. Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL format) on the VOTech wiki at http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any comments on the structure, concepts, and coverage of this v0.000000001 ontology would be appreciated. cheers, Elizabeth From edward.j.shaya.1 at gsfc.nasa.gov Wed Jun 1 11:41:33 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Wed, 01 Jun 2005 14:41:33 -0400 Subject: [Ontology] UCDs vs ontologies? In-Reply-To: References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: <429E015D.1080501@gsfc.nasa.gov> Elizabeth, Hurray. Another ontology fan. I have taken the liberty of using OwlDoc in Protege to create a browser readable version of your ontology. It is at http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html Would you mind if I integrate what you have into the more general ontology that I have been working on? http://archive.astro.umd.edu/ont/Documentation/index.html (And yes, Rob it does tend to get big, but one can trim it at any level. I rather see UCDs as a form of topic maps which is quite a close relative of Ontology. I prefer ontology because I believe one can do more rigorous reasoning and query with it, but many prefer topic maps because they are more loose and easy. ) Now that there are two of us interested in Ontology we can form a group. It has been suggested to me that Ontology discussions should reside in the data model group with "[Ontology]" in the subject Re:. So, I am ccing there too and will take the rest of this discussion there. I hope you are tuned in Elizabeth. Ed Elizabeth Auden wrote: > > Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL > format) on the VOTech wiki at > http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any > comments on the structure, concepts, and coverage of this v0.000000001 > ontology would be appreciated. > > cheers, > Elizabeth > From aam at astro.caltech.edu Wed Jun 1 12:30:06 2005 From: aam at astro.caltech.edu (Ashish Mahabal) Date: Wed, 1 Jun 2005 12:30:06 -0700 (PDT) Subject: [Ontology] UCDs vs ontologies? In-Reply-To: <429E015D.1080501@gsfc.nasa.gov> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> <429E015D.1080501@gsfc.nasa.gov> Message-ID: Hi Ed, Count me in too. I am the topic maps kind of person you mentioned, but also interested in ontologies. This should provide me some new impetus to working on UCDs, topic maps and ontologies. -ashish Ashish Mahabal, Caltech Astronomy, Pasadena, CA 91125 http://www.astro.caltech.edu/~aam aam at astro.caltech.edu Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER From mleoni at eso.org Thu Jun 2 00:41:17 2005 From: mleoni at eso.org (Marco C. Leoni) Date: Thu, 02 Jun 2005 09:41:17 +0200 Subject: [Fwd: cross-posting!!] Message-ID: <429EB81D.4040303@eso.org> -------- Original Message -------- Subject: cross-posting!! Date: Wed, 1 Jun 2005 18:08:41 +0200 From: Andrea Preite Martinez Dear all, could you please STOP cross-posting your messages? The manager of the IVOA mailing list was so kind to open for the discussion two new mailing lists. After half a day he is already asking himself if that was of any use, because people continues to send discussion mails also to ucd/voevents/... lists!! Thank you for your attention. Andrea ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 2 08:16:05 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 2 Jun 2005 17:16:05 +0200 Subject: Fwd: Format of concatenated UCD's Message-ID: Haven't heard any response to this message suggesting an alternative means of concatenating UCDs to permit their parsing by an XML parser. Here's a forward to make sure you all got it. No, we don't yet have UCD's operating under a schema, but we might want to some day and it will be much less painful if we make the switch now. As far as I can tell, there's no obivous reason for the present choice of separator. Rick > Up until now, it hasn't been possible to check the syntax of a UCD > list using > XML Schema: there's no way (yet) to express a list of elements > separated by > semi-colons. This is a shame, since it means that somebody else has > to do > this work - work which could have been delegated to the XML parser. > > Fortunately, XML Schema recognizes lists of elements separated by white > spaces, i.e. not > > "phot.calib;src.class" > > but > > "phot.calib src.class" > > If the official syntax of UCD lists included the latter possibility, > then the > entire content of a VO XML document could be parsed at once in a single > pass. > > Yes, it's too late for VOTable, but many other schemata are still in > their > infancy and would benefit dramatically from this possibility. While > the use > of UCD in VOTable has - up to now - been mostly in the form of > documentation, > VOEvent needs to be able to permit direct interpretation of the > meaning of > elements identified by UCD's (e.g. your robotic telescope only wants > to look > at GRB's and not vanilla SN). Either all subgroups like VOEvent wil > be forced > to define their own ontology or we enable all VO schemata to be able > to interpret > UCD's directly without any extra effort. The present syntax prevents > this. > > Schema examples of how this might work can be found at > > http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ > SchemaContentUCDListType > > (for the formal UCD list element type) and > > http://monet.uni-sw.gwdg.de/twiki/bin/view/UCD/SchemaContentUCD > > for an example of the current UCD placed in a schema which could be > concatenated in a UCD list element. > > In the short term, we can easily afford to let the two forms exists > side by side > (well, VOTable uses the old syntax, and new ones like VOEvent use the > newer > one). Those who have added parsers to read the old UCD lists will > easily be > able to adopt their code to read the new format, and those of us still > working on > the first versions of VO schemata can immediately benefit from being > able to > parse the ENTIRE document. > > F. Hessman > C. Hettlage > > ----------------------------------------------------------------------- > ------------------------- > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ----------------------------------------------------------------------- > -------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ----------------------------------------------------------------------- > -------------------------- > > ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Alberto.Micol at eso.org Thu Jun 2 08:37:34 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 2 Jun 2005 17:37:34 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: Message-ID: Dear Rick, On Jun 2, 2005, at 17:16, Frederic V. "Rick" Hessman wrote: > Haven't heard any response to this message suggesting an alternative > means > of concatenating UCDs to permit their parsing by an XML parser. > Here's a > forward to make sure you all got it. > > No, we don't yet have UCD's operating under a schema, but we might want > to some day and it will be much less painful if we make the switch now. > > As far as I can tell, there's no obivous reason for the present choice > of > separator. > > Rick > > > >> Up until now, it hasn't been possible to check the syntax of a UCD >> list using >> XML Schema: there's no way (yet) to express a list of elements >> separated by >> semi-colons. This is a shame, since it means that somebody else has >> to do >> this work - work which could have been delegated to the XML parser. >> >> Fortunately, XML Schema recognizes lists of elements separated by >> white >> spaces, i.e. not >> >> "phot.calib;src.class" >> >> but >> >> "phot.calib src.class" >> I'm not an XML expert, hence please allow me a naive (if not stupid) question, to try to understand better your point. If we write a UCD with a blank as a separator, does that mean that we are going away from a simple string in favour of an array of strings/words? What impact will such change have on the VOTable standard? Thanks, Alberto -- Alberto Micol ST-ECF HST Archive Scientist From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 2 09:24:25 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 2 Jun 2005 18:24:25 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: Message-ID: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> On 2 Jun 2005, at 5:37 pm, Alberto Micol wrote: >> Haven't heard any response to this message suggesting an alternative >> means >> of concatenating UCDs to permit their parsing by an XML parser. >> Here's a >> forward to make sure you all got it. >> >> No, we don't yet have UCD's operating under a schema, but we might >> want >> to some day and it will be much less painful if we make the switch >> now. >> >> As far as I can tell, there's no obivous reason for the present >> choice of >> separator. >>> Up until now, it hasn't been possible to check the syntax of a UCD >>> list using >>> XML Schema: there's no way (yet) to express a list of elements >>> separated by >>> semi-colons. This is a shame, since it means that somebody else has >>> to do >>> this work - work which could have been delegated to the XML parser. >>> >>> Fortunately, XML Schema recognizes lists of elements separated by >>> white >>> spaces, i.e. not >>> >>> "phot.calib;src.class" >>> >>> but >>> >>> "phot.calib src.class" >>> > > I'm not an XML expert, hence please allow me a naive (if not stupid) > question, > to try to understand better your point. > > If we write a UCD with a blank as a separator, does that mean that we > are > going away from a simple string in favour of an array of strings/words? > > What impact will such change have on the VOTable standard? The point is that the concatenation of UCDs in its present form (using a semicolon) is effectively an array of UCD strings. The question is only which character is defined as the separator. Since blanks are not allowed in UCDs, then a blank is as good a separator as a semicolon. Our argument is that - from an XML perspective - blanks are MUCH BETTER separators, since blanks permit us to check the syntax of a UCD entry in principle whereas a semicolon-separated array of UCD strings looks like a simple string to XML parsers. The UCD standard is about to be made official - this is our opportunity to make a very small change with a very big effect. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From norman at astro.gla.ac.uk Fri Jun 3 01:09:48 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 3 Jun 2005 10:09:48 +0200 Subject: Format of concatenated UCD's In-Reply-To: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> Message-ID: <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Frederic, On 2005 Jun 2 , at 18.24, Frederic V. "Rick" Hessman wrote: > The point is that the concatenation of UCDs in its present form (using > a > semicolon) is effectively an array of UCD strings. The question is > only > which character is defined as the separator. Since blanks are not > allowed > in UCDs, then a blank is as good a separator as a semicolon. Our > argument is that - from an XML perspective - blanks are MUCH BETTER > separators, since blanks permit us to check the syntax of a UCD entry > in principle whereas a semicolon-separated array of UCD strings looks > like a simple string to XML parsers. UCDs are orthogonal to XML, thus changing the UCD syntax because one particular XML technology allows you to peek inside attribute values (which are opaque in the XML data model), is the tail wagging the dog. Also, any meaningful checking of UCDs is going to have to do more than split the UCD at semicolons, so having your XML parser API do that for you doesn't seem much of a win. Blanks would also be a bad intra-UCD separator, since that would stop blanks being the natural inter-UCD separator. With the semicolon, one can naturally talk of a space-separated list of UCDs, with whatever meaning is appropriate in the context; without it, one cannot. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From Hessman at Astro.physik.Uni-Goettingen.DE Fri Jun 3 02:30:56 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 3 Jun 2005 11:30:56 +0200 Subject: Format of concatenated UCD's In-Reply-To: <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Message-ID: On 3 Jun 2005, at 10:09 am, Norman Gray wrote: > > Frederic, > > On 2005 Jun 2 , at 18.24, Frederic V. "Rick" Hessman wrote: > >> The point is that the concatenation of UCDs in its present form >> (using a >> semicolon) is effectively an array of UCD strings. The question is >> only >> which character is defined as the separator. Since blanks are not >> allowed >> in UCDs, then a blank is as good a separator as a semicolon. Our >> argument is that - from an XML perspective - blanks are MUCH BETTER >> separators, since blanks permit us to check the syntax of a UCD entry >> in principle whereas a semicolon-separated array of UCD strings looks >> like a simple string to XML parsers. > > UCDs are orthogonal to XML, thus changing the UCD syntax because one > particular XML technology allows you to peek inside attribute values > (which are opaque in the XML data model), is the tail wagging the dog. > > Also, any meaningful checking of UCDs is going to have to do more than > split the UCD at semicolons, so having your XML parser API do that for > you doesn't seem much of a win. > > Blanks would also be a bad intra-UCD separator, since that would stop > blanks being the natural inter-UCD separator. With the semicolon, one > can naturally talk of a space-separated list of UCDs, with whatever > meaning is appropriate in the context; without it, one cannot. You're right about having to worry about "intra-" versus "inter-" ; will have to think some more :-( You're wrong about XML attributes being "opaque" or "anonymous": they have a clearly defined base/type. If you define them as a string, it's because you've chosen to make them "opaque" to the parser, but many attributes aren't strings. "Opaque" strings are good for simple names but not necessarily good for UCDs. I would like to also disagree about UCDs and XML being orthogonal: a document with a UCD which doesn't conform to the standard is at best faulty and at worse a sign that it has been garbled in transmission, so you have to check the syntax at some point anyway. The question is whether you want to be very forgiving about garbage UCD's (which most XML parsers won't like if they get to check the syntax) and whether you want to maintain 2 parsers instead of 1 (assuming we could get XML parsers to do UCDs as well). Thanks for the bounce :-) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From norman at astro.gla.ac.uk Fri Jun 3 03:32:38 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 3 Jun 2005 12:32:38 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Message-ID: <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> Frederic, On 2005 Jun 3 , at 11.30, Frederic V. "Rick" Hessman wrote: > You're wrong about XML attributes being "opaque" or "anonymous": they > have a clearly defined > base/type. They have a type in XSchema, yes, but they're opaque in XML. OK, it's slightly more complicated than that, since as well as CDATA, attribute values can be ID, IDREF, and so on, or enumerated types [1]; but since UCDs don't conform to the production for NMTOKEN (admittedly only because of the presence of the semicolon), they can only go in CDATA attributes, which I'm pretty positive are opaque in the terms of the XML Infoset. That means they're opaque for DOM, SAX, anything based on DTDs, all non-validating parsers, lightweight fault-tolerant parsers, all sorts. This isn't quite hair-splitting (though I agree it's perilously close to it!). XSchema APIs are important, but they're not the only reasonable way to get at XML content. [1] > I would like to also disagree about UCDs and XML being orthogonal: a > document with a UCD which doesn't > conform to the standard is at best faulty and at worse a sign that it > has been garbled in transmission, > so you have to check the syntax at some point anyway. The question is > whether you want to be very > forgiving about garbage UCD's (which most XML parsers won't like if > they get to check the syntax) and > whether you want to maintain 2 parsers instead of 1 (assuming we could > get XML parsers to do UCDs > as well). UCDs are not just for VOTables, but for URLs, FITS headers, and database columns, too. The most common/visible current use of UCDs is in an XML context, but that's just coincidence. And I disagree, again, that an XSchema library/API can do any useful validation of UCDs (and the XML parser by itself can do nothing, for at that level the string is still opaque). Checking that a putative UCD matches the UCD production will catch a few extreme errors, but you surely have no hope of having the XSchema API catch `pos.eq.ra;meta.mian' or `pos.eq.ra;this.is.not.a.ucd'. Best wishes, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From francois at vizir.u-strasbg.fr Fri Jun 3 05:30:49 2005 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Fri, 03 Jun 2005 14:30:49 +0200 Subject: Fwd: Format of concatenated UCD's In-Reply-To: Your message of Thu, 2 Jun 2005 17:16:05 +0200 . Message-ID: <200506031230.j53CUn116123@vizir.u-strasbg.fr> It would not be a good idea in my opinion -- better to keep a UCD as a single-word (no blank). 2 reasons: 1. XML is not the only way of expressing UCDs --- UCDs must also be available in other contexts and your solution introduces a complication in these other contexts 2. Could be useful in the future to attach several UCDs to a quantity or some VO item -- then you would have to invent something special to code this array of UCDs in XML --Francois > >Haven't heard any response to this message suggesting an alternative means >of concatenating UCDs to permit their parsing by an XML parser. Here's a >forward to make sure you all got it. > >No, we don't yet have UCD's operating under a schema, but we might want >to some day and it will be much less painful if we make the switch now. > >As far as I can tell, there's no obivous reason for the present choice of >separator. > >Rick > > > ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 32 ================================================================================ From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 9 05:30:47 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 9 Jun 2005 14:30:47 +0200 Subject: Format of concatenated UCD's In-Reply-To: <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> Message-ID: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> After withdrawing my suggestion of replacing the UCD ';' separator, we went back to the drawing table. One of our students came up with a practicable solution: defining all UCD elements as a set of restricted strings defined by a regexp. The resulting (test) schema http://monet.uni-sw.gwdg.de/cgi-bin/xml_validation/scripts/ createUCDSchema.pl why not elegant (in the sense that a set of s is elegant) conforms exactly with the present usage, permitting lists of UCD groups (separated by spaces), each with optional semi-colon separators. This example script takes the official UCD list and parses it into the correct form. The parsing overhead is reasonable, especially since we're unlikely to expand the UCD list to tens of thousands of entries any time soon. I sense that there is some reluctance to have the UCDs parsed, though I haven't yet heard any good reason for allowing garbage UCDs in documents. I'd like to see the use of parsed UCDs alongside what the VOEvent group has been discussing as VOConcept (same syntax as UCDs, different purpose) which would allow elements such as e.g. (dummy example for an optical burst) where you can see that the combination of standard UCD syntax with VOConcept added is exactly what one needs to extend the present functionality while keeping the same usage. Yes, one can do this without syntax checking, but that's the whole point of VOEvent - to permit strict syntax checking by computers using standard elements. Comments? Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Thu Jun 9 14:19:15 2005 From: seaman at noao.edu (Rob Seaman) Date: Thu, 9 Jun 2005 14:19:15 -0700 Subject: Format of concatenated UCD's In-Reply-To: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: On Jun 9, 2005, at 5:30 AM, Frederic V. Rick Hessman wrote: > I'd like to see the use of parsed UCDs alongside what the VOEvent > group has been discussing as VOConcept (same syntax as UCDs, > different purpose) which would allow elements such as > > > e.g. > > > (dummy example for an optical burst) where you can see that the > combination of standard UCD syntax with VOConcept added is exactly > what one needs to extend the present functionality while keeping > the same usage. The last time I raised this issue (http://ivoa.net/forum/ucd/ 0504/0166.htm), the thread spiraled off into ontologies. Maybe we can try again. There appears to be a lot of friction resulting from some implicit requirement that UCDs and VOConcepts occupy the same namespace and be in thrall to the same standards process. From where I'm sitting, however, they appear to simply represent different problems with similar solutions. VOConcepts may want to borrow UCD syntax, but they don't have to therefore coexist in the same namespace. Is there some technical reason that Rick's example can't become "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the semantic underbrush. Please tell me why we can't have separate namespaces? I've resisted cross-posting. Please let me know if you believe this will be more productively addressed elsewhere. Rob Seaman NOAO From norman at astro.gla.ac.uk Fri Jun 10 06:48:15 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 10 Jun 2005 14:48:15 +0100 Subject: Format of concatenated UCD's In-Reply-To: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: <25ca1bb152954919a4a506b0d5ba0765@astro.gla.ac.uk> Frederic, On 2005 Jun 9 , at 13.30, Frederic V. "Rick" Hessman wrote: > http://monet.uni-sw.gwdg.de/cgi-bin/xml_validation/scripts/ > createUCDSchema.pl Cough. Unless I'm mistaken, your pattern there admits UCDs like "pos.eq.ra;instr.beam;meta.ucd". If we follow the logic of your approach, which wants Schemas to do all the validity checking, and so exclude such garbage UCDs, then you'll have produce an XSchema fragment which lists all the complete UCDs anyone might legitimately ever want, which I hope you would agree was unlikely to be useful. If you think that is going too far, then you agree that there will have to be some semantic validation of UCDs _after_ syntactical analysis, in which case there's no need to do any syntactical analysis beyond confirming that the UCDs conform to the production in the UCD standard. I'm afraid I don't understand what problem you're addressing. You appear to be thinking of some situation where there will be syntactical analysis of a UCD in a FITS header or an XML attribute, but no subsequent semantic analysis or use of that UCD, which is where garbage UCDs would naturally be detected and usefully reported. > I sense that there is some reluctance to have the UCDs parsed, though There's no reluctance on my part to have UCDs parsed, but they're parsed into character sequences, dots and semicolons, for separate subsequent semantic analysis (what does this UCD mean? does it mean anything?). When I parse the famous `colourless green ideas sleep furiously' I can do so perfectly successfully; attaching meaning to it is not my parser's problem. > I haven't yet heard any good reason for allowing garbage UCDs in > documents. This isn't an argument for allowing garbage UCDs anywhere. It's simply the argument that XML syntax-analysis tools have nothing to do with the semantic validation of UCDs: just because XSchema is a hammer, it doesn't follow that everything else is a nail. The premature semantic validation you're talking about would not improve data security; would make the system less, not more, robust; and be on the whole less usable, by reporting semantic errors at an inappropriately low (ie, syntactic) level. UCDs are not XML. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From Hessman at Astro.physik.Uni-Goettingen.DE Mon Jun 13 07:25:32 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 13 Jun 2005 16:25:32 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> > Is there some technical reason that Rick's example can't become > "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the > semantic underbrush. Please tell me why we can't have separate > namespaces? > I've resisted cross-posting. Please let me know if you believe this > will be more productively addressed elsewhere. There's no point in pushing the UCD-XML connection. While I don't agree with all of Norman's reasons for his more vehement rejection, he's right when he said "... just because XSchema is a hammer, it doesn't follow that everything else is a nail." While I want UCD to be a nail, I certainly don't have the right to make anyone adopt my hammer. The question then, is, whether something so XML-ish as namespaces will go over very well to those who just want their string. My guess is, NO. The question for VOEvent, where the use of UCDs would be nice and automatic syntax checking is a gift worth taking (we're parsing using a schema anyway, remember!) but where the present UCD usage is far too limited, is whether to split the usage into two parts, e.g. and loose the symantic flexibility of being able to form things like (where the fact that the burst happened in the optical is explicit, unlike the previous example). Those of you uninterested in VOEvent may think that this discussion is irrelevant to ucd-tech, but at least you should be aware of the desire among some of us to INSURE that the UCDs (or at least the most important ones) conform to the standard, and that expressing them in an XML schema is simply the easiest way - a document which doesn't conform to the standard is garbage because it'll take a human (or additional human-trained software) to deal with it and hence the universality is lost by definition. Again, this problem is undoubtably more acute in VOEvent than in other VO circles, but - hey - that's the way it is. IMHO this may mean that a parallel UCD-schema may have to be defined which lives a strange parallel life to the official list and which you can simply use..... or ignore. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Mon Jun 13 10:57:35 2005 From: seaman at noao.edu (Rob Seaman) Date: Mon, 13 Jun 2005 10:57:35 -0700 Subject: Format of concatenated UCD's In-Reply-To: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> Message-ID: <990768F3-4D4E-4FE5-BCC6-6B2BBAD20985@noao.edu> Rick Hessman replies to my message: >> Is there some technical reason that Rick's example can't become >> "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in >> the semantic underbrush. Please tell me why we can't have >> separate namespaces? > > The question then, is, whether something so XML-ish as namespaces > will go over very well to those who just want their string. My > guess is, NO. Surely the idea of a "namespace" is broader than its usage in XML. I gather from Rick's reply that he himself doesn't see anything wrong with my extension of his example. Could some UCD doyen resolve our guessing? This isn't an XML question, it is a pure UCD usage question. Rob Seaman NOAO From norman at astro.gla.ac.uk Wed Jun 15 10:01:49 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 15 Jun 2005 18:01:49 +0100 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: Rob, On 2005 Jun 9 , at 22.19, Rob Seaman wrote: > Is there some technical reason that Rick's example can't become > "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the > semantic underbrush. Please tell me why we can't have separate > namespaces? Myself, I don't think there's anything wrong with con:event.burst;ivoa:em.opt. The strong nervousness which others have about the use of UCD namespaces, as expressed for example in the UCD1+ document, I understand but do not fully share. There seem to be two issues. 1. (semantic) If you have a namespaced UCD atom, then not all software will understand it. This is true, but it's also rather in the nature of namespaces that they are an acknowledgement that the namespaced thing is special or non-standard, so that it will only be useful to certain processors. They also avoid the atom being confused with other atoms which happen to have the same name (this is of course The Point), but _usually_ give some indication of where a fuller explanation may be found. That is, they're a complication, but avoid a worse problem. 2. (syntactic) How do you associate a namespace prefix with a URI (for that is the only sane way of pinning down a namespace)? In the XML context, this is straightforward, since you can simply use the same namespace resolution algorithm as exists in XML (I believe it would be bad to specify a different one). That has the problems that it makes namespaced UCDs somewhat context-dependent, and that the namespace algorithm has some confusing edge cases. It represents more complication, but is perfectly manageable, I think. How do you do the association in non-XML contexts, such as FITS headers, or in a database? That's more complicated, and is probably inevitably messy. One possibility, I suppose, would be to follow the unstandardised but common XML habit of writing {namespace-uri}namespaced-thing, as in '{http://www.ivoa.net/ucd}em.opt'. Not pretty, and it could easily get very long-winded. All this is a long way of saying that there are technical worries about using namespaces, but that they don't seem to me to be killing ones. The advantage of using namespaces is that they allow sets of `ucds' like the VOConcepts to be defined, which don't clutter the generic UCD vocabulary, but which do inherit the precision in the UCD spec, and any updates follow it. ...it seems to me. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From norman at astro.gla.ac.uk Wed Jun 15 10:30:54 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 15 Jun 2005 18:30:54 +0100 Subject: Format of concatenated UCD's In-Reply-To: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> Message-ID: <7d7387b131dbc3b2b9e5ae54ebc30fc9@astro.gla.ac.uk> Rick, On 2005 Jun 13 , at 15.25, Frederic V. "Rick" Hessman wrote: > > > and loose the symantic flexibility of being able to form things like > > > > (where the fact that the burst happened in the optical is explicit, > unlike the previous example). For what it's worth, I think the second makes a lot more sense (though it would be "event.burst;em.opt", since the event in question IsA 'event.burst' rather than IsA 'em.opt'). Incidentally, this also provides quite a good example of the utility of namespaces. The semi-deprecation of namespaces seems to me to push folk toward the non-interoperable workaround illustrated by the first of Rick's two alternatives. Against that, it could be argued that the proposed 'event.' hierarchy is doing some of the work of a namespace by gathering all the event-related terms together, but that this `namespace' is blessed by being standardised. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From seaman at noao.edu Wed Jun 1 08:32:36 2005 From: seaman at noao.edu (Rob Seaman) Date: Wed, 1 Jun 2005 08:32:36 -0700 Subject: UCDs vs ontologies? In-Reply-To: <429DBE0C.7060905@cea.fr> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: On Jun 1, 2005, at 6:54 AM, Pierre Didelon wrote: > But do/must UCD be the solution to (all?) natural langage parsing? It would be premature to begin the work of the board by willy-nilly reassigning identifiers such as "em". It seems likely that we will need to be able to express the concepts of both "electromagnetism" and "emission". If there is emission, there is absorption. And sometimes we may want to express the combination of "electromagnetic emission" at the same time. On the other hand, we're told that the role of UCDs is distinct from that of ontologies. An ontology is an (attempt) at expressing the complete range of some knowledge domain. Astronomy is a big subject - its ontology will be big. Perhaps by analogy we can view an ontology as the unabridged dictionary for some subject, whereas UCDs are simply one way to build a glossary for a specific purpose. Glossaries are often small enough to be appended to a brief document. Personally, I think the VO community will need to develop several separate ontologies over time as well as several separate glossaries of UCDs or UCD-like constructs. It is not obvious that a glossary of UCDs for tabular convenience is equivalent to a glossary of UCDs for VOEvent convenience. An ontology can afford to be large and unwieldy to reach its goal of being complete and accurate. A UCD style glossary, on the other hand, will eventually reach an optimum size. Its utility will pass a point of diminishing returns. Too much precision engenders confusion. The availability of too many options results in overlapping shades of meaning. I gather the current list of UCDs was generated by looking at actual tables in the literature. This is just how the unabridged OED was created from words sieved from millions of quotations. Just like a dictionary, the work of maintaining the list of UCDs will continue indefinitely as new tabular usage is coined. I would suggest that the creation of this new list of UCD-like entities to describe astronomical "concepts" is fundamentally a different exercise. We may not be trying to generate a complete ontology with all interrelationships clearly drawn between all concepts, but we are trying to be complete in the sense of not leaving any gaps in the web of concepts. "Star" and "galaxy" will clearly make the final cut. "Star.white_dwarf" and "galaxy.spiral" most likely, too. But it won't take many levels to exhaust the utility of compiling such a list. I expect the final list to have hundreds of entries, not tens of thousands. One final point. The nature of this board is to participate in the process of certifying an official list of terms. I think the true utility of both glossaries and dictionaries will be achieved when facilities are available for creating and maintaining *unofficial* lists. For VOEvent, for instance, it seems likely that each project publishing events will adopt its own glossary pertinent to its own instrumentation and observations. We should support these activities and provide a framework for project specific glossaries. They will spring into existence whether or not we do so. At least if we support the creation of project specific glossaries, we can have some say in controlling a common semantic structure and a standardized distribution mechanism. This might also naturally lead to the next step of layering UCD glossaries on top of our emerging ontology (ies). A glossary, after all, is nothing but a well chosen list of words out of the dictionary. It is the dictionary that provides etymology, synonyms and antonyms, classification by part of speech, tenses and gender, pronunciation, ... Sorry for the cross-posting. If we can't restrain ourselves from generating all these mailing lists, I'm not sure what hope we have for a coherent set of UCD lists :-) Rob Seaman NOAO -------------- next part -------------- An HTML attachment was scrubbed... URL: From eca at mssl.ucl.ac.uk Wed Jun 1 08:42:25 2005 From: eca at mssl.ucl.ac.uk (Elizabeth Auden) Date: Wed, 1 Jun 2005 16:42:25 +0100 (BST) Subject: UCDs vs ontologies? In-Reply-To: References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: > On the other hand, we're told that the role of UCDs is distinct from that of > ontologies. An ontology is an (attempt) at expressing the complete range of > some knowledge domain. Astronomy is a big subject - its ontology will be > big. > Personally, I think the VO community will need to develop several separate > ontologies over time as well as several separate glossaries of UCDs or > UCD-like constructs. It is not obvious that a glossary of UCDs for tabular > convenience is equivalent to a glossary of UCDs for VOEvent convenience. An > ontology can afford to be large and unwieldy to reach its goal of being > complete and accurate. Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL format) on the VOTech wiki at http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any comments on the structure, concepts, and coverage of this v0.000000001 ontology would be appreciated. cheers, Elizabeth From edward.j.shaya.1 at gsfc.nasa.gov Wed Jun 1 11:41:33 2005 From: edward.j.shaya.1 at gsfc.nasa.gov (Ed Shaya) Date: Wed, 01 Jun 2005 14:41:33 -0400 Subject: [Ontology] UCDs vs ontologies? In-Reply-To: References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> Message-ID: <429E015D.1080501@gsfc.nasa.gov> Elizabeth, Hurray. Another ontology fan. I have taken the liberty of using OwlDoc in Protege to create a browser readable version of your ontology. It is at http://archive.astro.umd.edu/ont/Documentation/VOEVENT/index.html Would you mind if I integrate what you have into the more general ontology that I have been working on? http://archive.astro.umd.edu/ont/Documentation/index.html (And yes, Rob it does tend to get big, but one can trim it at any level. I rather see UCDs as a form of topic maps which is quite a close relative of Ontology. I prefer ontology because I believe one can do more rigorous reasoning and query with it, but many prefer topic maps because they are more loose and easy. ) Now that there are two of us interested in Ontology we can form a group. It has been suggested to me that Ontology discussions should reside in the data model group with "[Ontology]" in the subject Re:. So, I am ccing there too and will take the rest of this discussion there. I hope you are tuned in Elizabeth. Ed Elizabeth Auden wrote: > > Incidentally, I've posted a first go at a VOEvent ontology (OWL-DL > format) on the VOTech wiki at > http://wiki.eurovotech.org/bin/view/VOTech/VoEventOntology. Any > comments on the structure, concepts, and coverage of this v0.000000001 > ontology would be appreciated. > > cheers, > Elizabeth > From aam at astro.caltech.edu Wed Jun 1 12:30:06 2005 From: aam at astro.caltech.edu (Ashish Mahabal) Date: Wed, 1 Jun 2005 12:30:06 -0700 (PDT) Subject: [Ontology] UCDs vs ontologies? In-Reply-To: <429E015D.1080501@gsfc.nasa.gov> References: <20050531150728.fn26pj7v9fa8okc8@webmail.sic.rm.cnr.it> <94643280d46f33e5c88952d520f13f55@Astro.physik.Uni-Goettingen.DE> <429D79B3.3@cea.fr> <0a75e9e971886f955bcd71d196c35f79@Astro.physik.Uni-Goettingen.DE> <429DBE0C.7060905@cea.fr> <429E015D.1080501@gsfc.nasa.gov> Message-ID: Hi Ed, Count me in too. I am the topic maps kind of person you mentioned, but also interested in ontologies. This should provide me some new impetus to working on UCDs, topic maps and ontologies. -ashish Ashish Mahabal, Caltech Astronomy, Pasadena, CA 91125 http://www.astro.caltech.edu/~aam aam at astro.caltech.edu Backups? We doan *NEED* no steenking baX%^~,VbKx NO CARRIER From mleoni at eso.org Thu Jun 2 00:41:17 2005 From: mleoni at eso.org (Marco C. Leoni) Date: Thu, 02 Jun 2005 09:41:17 +0200 Subject: [Fwd: cross-posting!!] Message-ID: <429EB81D.4040303@eso.org> -------- Original Message -------- Subject: cross-posting!! Date: Wed, 1 Jun 2005 18:08:41 +0200 From: Andrea Preite Martinez Dear all, could you please STOP cross-posting your messages? The manager of the IVOA mailing list was so kind to open for the discussion two new mailing lists. After half a day he is already asking himself if that was of any use, because people continues to send discussion mails also to ucd/voevents/... lists!! Thank you for your attention. Andrea ============================================================================== Andrea Preite Martinez andrea at rm.iasf.cnr.it Istituto di Astrofisica Spaziale Tel.:+39.06.4993.4641 Area di Ricerca di Tor Vergata Fax.:+39.06.2066.0188 Via del Fosso del Cavaliere 100 Cell:+39.339.3817355 00133 Roma ============================================================================== -------------- next part -------------- An HTML attachment was scrubbed... URL: From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 2 08:16:05 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 2 Jun 2005 17:16:05 +0200 Subject: Fwd: Format of concatenated UCD's Message-ID: Haven't heard any response to this message suggesting an alternative means of concatenating UCDs to permit their parsing by an XML parser. Here's a forward to make sure you all got it. No, we don't yet have UCD's operating under a schema, but we might want to some day and it will be much less painful if we make the switch now. As far as I can tell, there's no obivous reason for the present choice of separator. Rick > Up until now, it hasn't been possible to check the syntax of a UCD > list using > XML Schema: there's no way (yet) to express a list of elements > separated by > semi-colons. This is a shame, since it means that somebody else has > to do > this work - work which could have been delegated to the XML parser. > > Fortunately, XML Schema recognizes lists of elements separated by white > spaces, i.e. not > > "phot.calib;src.class" > > but > > "phot.calib src.class" > > If the official syntax of UCD lists included the latter possibility, > then the > entire content of a VO XML document could be parsed at once in a single > pass. > > Yes, it's too late for VOTable, but many other schemata are still in > their > infancy and would benefit dramatically from this possibility. While > the use > of UCD in VOTable has - up to now - been mostly in the form of > documentation, > VOEvent needs to be able to permit direct interpretation of the > meaning of > elements identified by UCD's (e.g. your robotic telescope only wants > to look > at GRB's and not vanilla SN). Either all subgroups like VOEvent wil > be forced > to define their own ontology or we enable all VO schemata to be able > to interpret > UCD's directly without any extra effort. The present syntax prevents > this. > > Schema examples of how this might work can be found at > > http://monet.uni-sw.gwdg.de/twiki/bin/view/VOEvent/ > SchemaContentUCDListType > > (for the formal UCD list element type) and > > http://monet.uni-sw.gwdg.de/twiki/bin/view/UCD/SchemaContentUCD > > for an example of the current UCD placed in a schema which could be > concatenated in a UCD list element. > > In the short term, we can easily afford to let the two forms exists > side by side > (well, VOTable uses the old syntax, and new ones like VOEvent use the > newer > one). Those who have added parsers to read the old UCD lists will > easily be > able to adopt their code to read the new format, and those of us still > working on > the first versions of VO schemata can immediately benefit from being > able to > parse the ENTIRE document. > > F. Hessman > C. Hettlage > > ----------------------------------------------------------------------- > ------------------------- > Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE > Universitaets-Sternwarte Tel. +49-551-39-5052 > Geismarlandstr. 11 Fax +49-551-39-5043 > 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman > ----------------------------------------------------------------------- > -------------------------- > MONET: a MOnitoring NEtwork of Telescopes > http://monet.uni-goettingen.de > ----------------------------------------------------------------------- > -------------------------- > > ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From Alberto.Micol at eso.org Thu Jun 2 08:37:34 2005 From: Alberto.Micol at eso.org (Alberto Micol) Date: Thu, 2 Jun 2005 17:37:34 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: Message-ID: Dear Rick, On Jun 2, 2005, at 17:16, Frederic V. "Rick" Hessman wrote: > Haven't heard any response to this message suggesting an alternative > means > of concatenating UCDs to permit their parsing by an XML parser. > Here's a > forward to make sure you all got it. > > No, we don't yet have UCD's operating under a schema, but we might want > to some day and it will be much less painful if we make the switch now. > > As far as I can tell, there's no obivous reason for the present choice > of > separator. > > Rick > > > >> Up until now, it hasn't been possible to check the syntax of a UCD >> list using >> XML Schema: there's no way (yet) to express a list of elements >> separated by >> semi-colons. This is a shame, since it means that somebody else has >> to do >> this work - work which could have been delegated to the XML parser. >> >> Fortunately, XML Schema recognizes lists of elements separated by >> white >> spaces, i.e. not >> >> "phot.calib;src.class" >> >> but >> >> "phot.calib src.class" >> I'm not an XML expert, hence please allow me a naive (if not stupid) question, to try to understand better your point. If we write a UCD with a blank as a separator, does that mean that we are going away from a simple string in favour of an array of strings/words? What impact will such change have on the VOTable standard? Thanks, Alberto -- Alberto Micol ST-ECF HST Archive Scientist From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 2 09:24:25 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 2 Jun 2005 18:24:25 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: Message-ID: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> On 2 Jun 2005, at 5:37 pm, Alberto Micol wrote: >> Haven't heard any response to this message suggesting an alternative >> means >> of concatenating UCDs to permit their parsing by an XML parser. >> Here's a >> forward to make sure you all got it. >> >> No, we don't yet have UCD's operating under a schema, but we might >> want >> to some day and it will be much less painful if we make the switch >> now. >> >> As far as I can tell, there's no obivous reason for the present >> choice of >> separator. >>> Up until now, it hasn't been possible to check the syntax of a UCD >>> list using >>> XML Schema: there's no way (yet) to express a list of elements >>> separated by >>> semi-colons. This is a shame, since it means that somebody else has >>> to do >>> this work - work which could have been delegated to the XML parser. >>> >>> Fortunately, XML Schema recognizes lists of elements separated by >>> white >>> spaces, i.e. not >>> >>> "phot.calib;src.class" >>> >>> but >>> >>> "phot.calib src.class" >>> > > I'm not an XML expert, hence please allow me a naive (if not stupid) > question, > to try to understand better your point. > > If we write a UCD with a blank as a separator, does that mean that we > are > going away from a simple string in favour of an array of strings/words? > > What impact will such change have on the VOTable standard? The point is that the concatenation of UCDs in its present form (using a semicolon) is effectively an array of UCD strings. The question is only which character is defined as the separator. Since blanks are not allowed in UCDs, then a blank is as good a separator as a semicolon. Our argument is that - from an XML perspective - blanks are MUCH BETTER separators, since blanks permit us to check the syntax of a UCD entry in principle whereas a semicolon-separated array of UCD strings looks like a simple string to XML parsers. The UCD standard is about to be made official - this is our opportunity to make a very small change with a very big effect. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From norman at astro.gla.ac.uk Fri Jun 3 01:09:48 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 3 Jun 2005 10:09:48 +0200 Subject: Format of concatenated UCD's In-Reply-To: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> Message-ID: <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Frederic, On 2005 Jun 2 , at 18.24, Frederic V. "Rick" Hessman wrote: > The point is that the concatenation of UCDs in its present form (using > a > semicolon) is effectively an array of UCD strings. The question is > only > which character is defined as the separator. Since blanks are not > allowed > in UCDs, then a blank is as good a separator as a semicolon. Our > argument is that - from an XML perspective - blanks are MUCH BETTER > separators, since blanks permit us to check the syntax of a UCD entry > in principle whereas a semicolon-separated array of UCD strings looks > like a simple string to XML parsers. UCDs are orthogonal to XML, thus changing the UCD syntax because one particular XML technology allows you to peek inside attribute values (which are opaque in the XML data model), is the tail wagging the dog. Also, any meaningful checking of UCDs is going to have to do more than split the UCD at semicolons, so having your XML parser API do that for you doesn't seem much of a win. Blanks would also be a bad intra-UCD separator, since that would stop blanks being the natural inter-UCD separator. With the semicolon, one can naturally talk of a space-separated list of UCDs, with whatever meaning is appropriate in the context; without it, one cannot. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From Hessman at Astro.physik.Uni-Goettingen.DE Fri Jun 3 02:30:56 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Fri, 3 Jun 2005 11:30:56 +0200 Subject: Format of concatenated UCD's In-Reply-To: <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Message-ID: On 3 Jun 2005, at 10:09 am, Norman Gray wrote: > > Frederic, > > On 2005 Jun 2 , at 18.24, Frederic V. "Rick" Hessman wrote: > >> The point is that the concatenation of UCDs in its present form >> (using a >> semicolon) is effectively an array of UCD strings. The question is >> only >> which character is defined as the separator. Since blanks are not >> allowed >> in UCDs, then a blank is as good a separator as a semicolon. Our >> argument is that - from an XML perspective - blanks are MUCH BETTER >> separators, since blanks permit us to check the syntax of a UCD entry >> in principle whereas a semicolon-separated array of UCD strings looks >> like a simple string to XML parsers. > > UCDs are orthogonal to XML, thus changing the UCD syntax because one > particular XML technology allows you to peek inside attribute values > (which are opaque in the XML data model), is the tail wagging the dog. > > Also, any meaningful checking of UCDs is going to have to do more than > split the UCD at semicolons, so having your XML parser API do that for > you doesn't seem much of a win. > > Blanks would also be a bad intra-UCD separator, since that would stop > blanks being the natural inter-UCD separator. With the semicolon, one > can naturally talk of a space-separated list of UCDs, with whatever > meaning is appropriate in the context; without it, one cannot. You're right about having to worry about "intra-" versus "inter-" ; will have to think some more :-( You're wrong about XML attributes being "opaque" or "anonymous": they have a clearly defined base/type. If you define them as a string, it's because you've chosen to make them "opaque" to the parser, but many attributes aren't strings. "Opaque" strings are good for simple names but not necessarily good for UCDs. I would like to also disagree about UCDs and XML being orthogonal: a document with a UCD which doesn't conform to the standard is at best faulty and at worse a sign that it has been garbled in transmission, so you have to check the syntax at some point anyway. The question is whether you want to be very forgiving about garbage UCD's (which most XML parsers won't like if they get to check the syntax) and whether you want to maintain 2 parsers instead of 1 (assuming we could get XML parsers to do UCDs as well). Thanks for the bounce :-) Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From norman at astro.gla.ac.uk Fri Jun 3 03:32:38 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 3 Jun 2005 12:32:38 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> Message-ID: <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> Frederic, On 2005 Jun 3 , at 11.30, Frederic V. "Rick" Hessman wrote: > You're wrong about XML attributes being "opaque" or "anonymous": they > have a clearly defined > base/type. They have a type in XSchema, yes, but they're opaque in XML. OK, it's slightly more complicated than that, since as well as CDATA, attribute values can be ID, IDREF, and so on, or enumerated types [1]; but since UCDs don't conform to the production for NMTOKEN (admittedly only because of the presence of the semicolon), they can only go in CDATA attributes, which I'm pretty positive are opaque in the terms of the XML Infoset. That means they're opaque for DOM, SAX, anything based on DTDs, all non-validating parsers, lightweight fault-tolerant parsers, all sorts. This isn't quite hair-splitting (though I agree it's perilously close to it!). XSchema APIs are important, but they're not the only reasonable way to get at XML content. [1] > I would like to also disagree about UCDs and XML being orthogonal: a > document with a UCD which doesn't > conform to the standard is at best faulty and at worse a sign that it > has been garbled in transmission, > so you have to check the syntax at some point anyway. The question is > whether you want to be very > forgiving about garbage UCD's (which most XML parsers won't like if > they get to check the syntax) and > whether you want to maintain 2 parsers instead of 1 (assuming we could > get XML parsers to do UCDs > as well). UCDs are not just for VOTables, but for URLs, FITS headers, and database columns, too. The most common/visible current use of UCDs is in an XML context, but that's just coincidence. And I disagree, again, that an XSchema library/API can do any useful validation of UCDs (and the XML parser by itself can do nothing, for at that level the string is still opaque). Checking that a putative UCD matches the UCD production will catch a few extreme errors, but you surely have no hope of having the XSchema API catch `pos.eq.ra;meta.mian' or `pos.eq.ra;this.is.not.a.ucd'. Best wishes, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From francois at vizir.u-strasbg.fr Fri Jun 3 05:30:49 2005 From: francois at vizir.u-strasbg.fr (Francois Ochsenbein) Date: Fri, 03 Jun 2005 14:30:49 +0200 Subject: Fwd: Format of concatenated UCD's In-Reply-To: Your message of Thu, 2 Jun 2005 17:16:05 +0200 . Message-ID: <200506031230.j53CUn116123@vizir.u-strasbg.fr> It would not be a good idea in my opinion -- better to keep a UCD as a single-word (no blank). 2 reasons: 1. XML is not the only way of expressing UCDs --- UCDs must also be available in other contexts and your solution introduces a complication in these other contexts 2. Could be useful in the future to attach several UCDs to a quantity or some VO item -- then you would have to invent something special to code this array of UCDs in XML --Francois > >Haven't heard any response to this message suggesting an alternative means >of concatenating UCDs to permit their parsing by an XML parser. Here's a >forward to make sure you all got it. > >No, we don't yet have UCD's operating under a schema, but we might want >to some day and it will be much less painful if we make the switch now. > >As far as I can tell, there's no obivous reason for the present choice of >separator. > >Rick > > > ================================================================================ Francois Ochsenbein ------ Observatoire Astronomique de Strasbourg 11, rue de l'Universite F-67000 STRASBOURG Phone: +33-(0)390 24 24 29 Email: francois at astro.u-strasbg.fr (France) Fax: +33-(0)390 24 24 32 ================================================================================ From Hessman at Astro.physik.Uni-Goettingen.DE Thu Jun 9 05:30:47 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Thu, 9 Jun 2005 14:30:47 +0200 Subject: Format of concatenated UCD's In-Reply-To: <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> Message-ID: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> After withdrawing my suggestion of replacing the UCD ';' separator, we went back to the drawing table. One of our students came up with a practicable solution: defining all UCD elements as a set of restricted strings defined by a regexp. The resulting (test) schema http://monet.uni-sw.gwdg.de/cgi-bin/xml_validation/scripts/ createUCDSchema.pl why not elegant (in the sense that a set of s is elegant) conforms exactly with the present usage, permitting lists of UCD groups (separated by spaces), each with optional semi-colon separators. This example script takes the official UCD list and parses it into the correct form. The parsing overhead is reasonable, especially since we're unlikely to expand the UCD list to tens of thousands of entries any time soon. I sense that there is some reluctance to have the UCDs parsed, though I haven't yet heard any good reason for allowing garbage UCDs in documents. I'd like to see the use of parsed UCDs alongside what the VOEvent group has been discussing as VOConcept (same syntax as UCDs, different purpose) which would allow elements such as e.g. (dummy example for an optical burst) where you can see that the combination of standard UCD syntax with VOConcept added is exactly what one needs to extend the present functionality while keeping the same usage. Yes, one can do this without syntax checking, but that's the whole point of VOEvent - to permit strict syntax checking by computers using standard elements. Comments? Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Thu Jun 9 14:19:15 2005 From: seaman at noao.edu (Rob Seaman) Date: Thu, 9 Jun 2005 14:19:15 -0700 Subject: Format of concatenated UCD's In-Reply-To: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: On Jun 9, 2005, at 5:30 AM, Frederic V. Rick Hessman wrote: > I'd like to see the use of parsed UCDs alongside what the VOEvent > group has been discussing as VOConcept (same syntax as UCDs, > different purpose) which would allow elements such as > > > e.g. > > > (dummy example for an optical burst) where you can see that the > combination of standard UCD syntax with VOConcept added is exactly > what one needs to extend the present functionality while keeping > the same usage. The last time I raised this issue (http://ivoa.net/forum/ucd/ 0504/0166.htm), the thread spiraled off into ontologies. Maybe we can try again. There appears to be a lot of friction resulting from some implicit requirement that UCDs and VOConcepts occupy the same namespace and be in thrall to the same standards process. From where I'm sitting, however, they appear to simply represent different problems with similar solutions. VOConcepts may want to borrow UCD syntax, but they don't have to therefore coexist in the same namespace. Is there some technical reason that Rick's example can't become "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the semantic underbrush. Please tell me why we can't have separate namespaces? I've resisted cross-posting. Please let me know if you believe this will be more productively addressed elsewhere. Rob Seaman NOAO From norman at astro.gla.ac.uk Fri Jun 10 06:48:15 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 10 Jun 2005 14:48:15 +0100 Subject: Format of concatenated UCD's In-Reply-To: <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: <25ca1bb152954919a4a506b0d5ba0765@astro.gla.ac.uk> Frederic, On 2005 Jun 9 , at 13.30, Frederic V. "Rick" Hessman wrote: > http://monet.uni-sw.gwdg.de/cgi-bin/xml_validation/scripts/ > createUCDSchema.pl Cough. Unless I'm mistaken, your pattern there admits UCDs like "pos.eq.ra;instr.beam;meta.ucd". If we follow the logic of your approach, which wants Schemas to do all the validity checking, and so exclude such garbage UCDs, then you'll have produce an XSchema fragment which lists all the complete UCDs anyone might legitimately ever want, which I hope you would agree was unlikely to be useful. If you think that is going too far, then you agree that there will have to be some semantic validation of UCDs _after_ syntactical analysis, in which case there's no need to do any syntactical analysis beyond confirming that the UCDs conform to the production in the UCD standard. I'm afraid I don't understand what problem you're addressing. You appear to be thinking of some situation where there will be syntactical analysis of a UCD in a FITS header or an XML attribute, but no subsequent semantic analysis or use of that UCD, which is where garbage UCDs would naturally be detected and usefully reported. > I sense that there is some reluctance to have the UCDs parsed, though There's no reluctance on my part to have UCDs parsed, but they're parsed into character sequences, dots and semicolons, for separate subsequent semantic analysis (what does this UCD mean? does it mean anything?). When I parse the famous `colourless green ideas sleep furiously' I can do so perfectly successfully; attaching meaning to it is not my parser's problem. > I haven't yet heard any good reason for allowing garbage UCDs in > documents. This isn't an argument for allowing garbage UCDs anywhere. It's simply the argument that XML syntax-analysis tools have nothing to do with the semantic validation of UCDs: just because XSchema is a hammer, it doesn't follow that everything else is a nail. The premature semantic validation you're talking about would not improve data security; would make the system less, not more, robust; and be on the whole less usable, by reporting semantic errors at an inappropriately low (ie, syntactic) level. UCDs are not XML. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From Hessman at Astro.physik.Uni-Goettingen.DE Mon Jun 13 07:25:32 2005 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V. "Rick" Hessman) Date: Mon, 13 Jun 2005 16:25:32 +0200 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> > Is there some technical reason that Rick's example can't become > "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the > semantic underbrush. Please tell me why we can't have separate > namespaces? > I've resisted cross-posting. Please let me know if you believe this > will be more productively addressed elsewhere. There's no point in pushing the UCD-XML connection. While I don't agree with all of Norman's reasons for his more vehement rejection, he's right when he said "... just because XSchema is a hammer, it doesn't follow that everything else is a nail." While I want UCD to be a nail, I certainly don't have the right to make anyone adopt my hammer. The question then, is, whether something so XML-ish as namespaces will go over very well to those who just want their string. My guess is, NO. The question for VOEvent, where the use of UCDs would be nice and automatic syntax checking is a gift worth taking (we're parsing using a schema anyway, remember!) but where the present UCD usage is far too limited, is whether to split the usage into two parts, e.g. and loose the symantic flexibility of being able to form things like (where the fact that the burst happened in the optical is explicit, unlike the previous example). Those of you uninterested in VOEvent may think that this discussion is irrelevant to ucd-tech, but at least you should be aware of the desire among some of us to INSURE that the UCDs (or at least the most important ones) conform to the standard, and that expressing them in an XML schema is simply the easiest way - a document which doesn't conform to the standard is garbage because it'll take a human (or additional human-trained software) to deal with it and hence the universality is lost by definition. Again, this problem is undoubtably more acute in VOEvent than in other VO circles, but - hey - that's the way it is. IMHO this may mean that a parallel UCD-schema may have to be defined which lives a strange parallel life to the official list and which you can simply use..... or ignore. Rick ------------------------------------------------------------------------ ------------------------ Dr. Frederic V. Hessman Hessman at Astro.physik.Uni-Goettingen.DE Universitaets-Sternwarte Tel. +49-551-39-5052 Geismarlandstr. 11 Fax +49-551-39-5043 37083 Goettingen http://www.uni-sw.gwdg.de/~hessman ------------------------------------------------------------------------ ------------------------- MONET: a MOnitoring NEtwork of Telescopes http://monet.uni-goettingen.de ------------------------------------------------------------------------ ------------------------- From seaman at noao.edu Mon Jun 13 10:57:35 2005 From: seaman at noao.edu (Rob Seaman) Date: Mon, 13 Jun 2005 10:57:35 -0700 Subject: Format of concatenated UCD's In-Reply-To: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> Message-ID: <990768F3-4D4E-4FE5-BCC6-6B2BBAD20985@noao.edu> Rick Hessman replies to my message: >> Is there some technical reason that Rick's example can't become >> "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in >> the semantic underbrush. Please tell me why we can't have >> separate namespaces? > > The question then, is, whether something so XML-ish as namespaces > will go over very well to those who just want their string. My > guess is, NO. Surely the idea of a "namespace" is broader than its usage in XML. I gather from Rick's reply that he himself doesn't see anything wrong with my extension of his example. Could some UCD doyen resolve our guessing? This isn't an XML question, it is a pure UCD usage question. Rob Seaman NOAO From norman at astro.gla.ac.uk Wed Jun 15 10:01:49 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 15 Jun 2005 18:01:49 +0100 Subject: Format of concatenated UCD's In-Reply-To: References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> Message-ID: Rob, On 2005 Jun 9 , at 22.19, Rob Seaman wrote: > Is there some technical reason that Rick's example can't become > "con:event.burst ucd:em.opt"? Let's try to avoid getting lost in the > semantic underbrush. Please tell me why we can't have separate > namespaces? Myself, I don't think there's anything wrong with con:event.burst;ivoa:em.opt. The strong nervousness which others have about the use of UCD namespaces, as expressed for example in the UCD1+ document, I understand but do not fully share. There seem to be two issues. 1. (semantic) If you have a namespaced UCD atom, then not all software will understand it. This is true, but it's also rather in the nature of namespaces that they are an acknowledgement that the namespaced thing is special or non-standard, so that it will only be useful to certain processors. They also avoid the atom being confused with other atoms which happen to have the same name (this is of course The Point), but _usually_ give some indication of where a fuller explanation may be found. That is, they're a complication, but avoid a worse problem. 2. (syntactic) How do you associate a namespace prefix with a URI (for that is the only sane way of pinning down a namespace)? In the XML context, this is straightforward, since you can simply use the same namespace resolution algorithm as exists in XML (I believe it would be bad to specify a different one). That has the problems that it makes namespaced UCDs somewhat context-dependent, and that the namespace algorithm has some confusing edge cases. It represents more complication, but is perfectly manageable, I think. How do you do the association in non-XML contexts, such as FITS headers, or in a database? That's more complicated, and is probably inevitably messy. One possibility, I suppose, would be to follow the unstandardised but common XML habit of writing {namespace-uri}namespaced-thing, as in '{http://www.ivoa.net/ucd}em.opt'. Not pretty, and it could easily get very long-winded. All this is a long way of saying that there are technical worries about using namespaces, but that they don't seem to me to be killing ones. The advantage of using namespaces is that they allow sets of `ucds' like the VOConcepts to be defined, which don't clutter the generic UCD vocabulary, but which do inherit the precision in the UCD spec, and any updates follow it. ...it seems to me. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk From norman at astro.gla.ac.uk Wed Jun 15 10:30:54 2005 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 15 Jun 2005 18:30:54 +0100 Subject: Format of concatenated UCD's In-Reply-To: <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> References: <487e7de262d86c3f3e6562dce4098817@Astro.physik.Uni-Goettingen.DE> <9074921429255f71b00427fa54481bdb@astro.gla.ac.uk> <66688e312c569fab3ce802b2109c91aa@astro.gla.ac.uk> <0bec4b12d833c5c1ea1d1177fefc889f@Astro.physik.Uni-Goettingen.DE> <375645907e52999b297bf8ea183b17c7@Astro.physik.Uni-Goettingen.DE> Message-ID: <7d7387b131dbc3b2b9e5ae54ebc30fc9@astro.gla.ac.uk> Rick, On 2005 Jun 13 , at 15.25, Frederic V. "Rick" Hessman wrote: > > > and loose the symantic flexibility of being able to form things like > > > > (where the fact that the burst happened in the optical is explicit, > unlike the previous example). For what it's worth, I think the second makes a lot more sense (though it would be "event.burst;em.opt", since the event in question IsA 'event.burst' rather than IsA 'em.opt'). Incidentally, this also provides quite a good example of the utility of namespaces. The semi-deprecation of namespaces seems to me to push folk toward the non-interoperable workaround illustrated by the first of Rick's two alternatives. Against that, it could be argued that the proposed 'event.' hierarchy is doing some of the work of a namespace by gathering all the event-related terms together, but that this `namespace' is blessed by being standardised. All the best, Norman -- ---------------------------------------------------------------------- Norman Gray : Physics & Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk