From Hessman at Astro.physik.Uni-Goettingen.DE Fri Jun 1 00:01:53 2012 From: Hessman at Astro.physik.Uni-Goettingen.DE (Frederic V.Hessman) Date: Fri, 1 Jun 2012 09:01:53 +0200 Subject: Fwd: SKOS concepts in VOTable References: Message-ID: <48A93A81-4C34-4E04-A813-B5BEC44055A5@Astro.physik.Uni-Goettingen.DE> (an exchange which accidentally didn't make the list) Dear Norman et al., I still think life would be easier if one knew exactly what to expect up front - say, - "type" means the link is meaningfully semantic is some sense, but you have to figure it out for yourself. - "rdf" means, well, RDF/SKOS/... - "doc" means the link leads to documentation - ... or even Norman's new favorite, "seealso", meaning the link is somehow related (which sounds a bit like "random" to me, but grab bags can be fun). These and other tags would tell you exactly what to expect (and hence whether your software should even bother to try to follow the link). On the other hand, if everything was trivial, we'd put a lot of students and software engineers out of a job. I can only re-iterate, that I'll ultimately buy whatever Norman says will work - but it would be nice to know that it is indeed going to work. Let's go for and haggle a bit more about the details. Rick On 31 May 2012, at 22:57, Norman Gray wrote: > On 2012 May 31, at 21:17, Frederic V. Hessman wrote: > >> i'll buy this, but with this argument, you can, e.g., argue for the abolishment of mime types (or, for that matter, file extensions): after all, your clever programmer can always write a parser that can figure out if the bits coming off the stream correspond to something which she should be able to deal with - it's just a question of knowing a few (hundred) bit patterns and bit hints - easy, and by definition future-compatible with any functioning software. > > But no -- all this is orthogonal to MIME types. I carefully didn't say what you get back when you dereference, say, http://purl.org/astronomy/vocab/DataObjectTypes/Image. My expectation, of course, is that it's RDF, but it could be anything, including HTML documentation of the concept, or some future IVOA document standard (preserve us from that!, but it's possible in principle). > > The parsing would all be driven by MIME types: there's certainly no content-sniffing going on. > > What you get back depends on what you ask for, and it would be wise to require providers of IVOA standards to provide both HTML and RDF. In this case, if you ask for RDF, you get: > > % curl -i -H accept:application/rdf+xml http://purl.org/astronomy/vocab/DataObjectTypes/Image > HTTP/1.1 302 Moved Temporarily > Date: Thu, 31 May 2012 20:37:35 GMT > Server: 1060 NetKernel v3.3 - Powered by Jetty > Location: http://votheory.obspm.fr/existenceService?uri=http://purl.org/astronomy/vocab/DataObjectTypes/Image > Content-Type: text/html; charset=iso-8859-1 > X-Purl: 2.0; http://localhost:8080 > Expires: Thu, 01 Jan 1970 00:00:00 GMT > Content-Length: 332 > > > > > 302 Found > > >

Found

> The resource requested is available here.

> > > % curl -H accept:application/rdf+xml 'http://votheory.obspm.fr/existenceService?uri=http://purl.org/astronomy/vocab/DataObjectTypes/Image' > > xmlns:skos="http://www.w3.org/2004/02/skos/core#" > xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#" > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > >> > > Image > > 2 > 2011-09-02T08:28:37Z > moreau > 2011-09-02T08:28:37Z > > > moreau > > > % > > At this point we know, if we didn't know it before, that .../Image is a SKOS Concept, so we can switch on that as assuredly as if we had had @content-role='skosconcept'. And our application probably _would_ know this before, because if .../Image means anything to us at all, one of the things we know about it is that it's a SKOS Concept. > > If you ask for RDF, and it's not available, then you can't find out about the concept on the fly. But that's OK, because I imagine that in most cases, an application will just look up the string value of the URI in some internal table, and the solution reduces to the same functionality we have with UCDs. Not great, but enough to build applications on. > >> In fact, why bother to even have content-role attributes at all: simply throw the link at them and, if they're good, they'll be able to handle it. Hey! - we're all good, of course, so no problem! ;-) > > No, I'm not saying that @content-role='type' is doing no work at all. The (non-normative) text in appendix A.1 of the VOTable spec mentions 'query', 'hints' and 'doc' as possible roles -- those are indicating very different species of link relationships. What content-role='type' is saying is that there is _some_ sort of 'is-a' relationship here, but being agnostic about the precise relationship, on the grounds that the precise details can be deduced from the type of the 'type': if it's a SKOS concept, then the VOTable column is in some way related to that concept; if it were a UCD, then the column would represent a number which could appear in a database column, and so on. > > Given a free hand, I'd be a lot more precise about the relationships, through a slightly different mechanism. But this is VOTable, so minimal pragmatic changes are the order of the day, while preserving as much flexibility as possible. From norman at astro.gla.ac.uk Fri Jun 1 05:24:48 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 1 Jun 2012 13:24:48 +0100 Subject: SKOS concepts in VOTable In-Reply-To: References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> Message-ID: <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> Mark and all, hello. On 2012 May 31, at 23:15, Mark Taylor wrote: > On Thu, 31 May 2012, Norman Gray wrote: > >> On 2012 May 28, at 10:54, Mark Taylor wrote: >> >>>> Solution 3 : >>>> Use subelements for . >>>> PROs : already allowed in VOTable 1.2. URIs can be expressed in href="". >>>> Possible to use content-type and content-role attributes to give additional >>>> context. Possible to have multiple for one . >>>> CONs : not sure how parsers would handle this or how this can be used >>>> in TAP... >>> >>> Since LINK is already present, and seems to be syntactically and >>> semantically capable of doing what's required here, it looks to me >>> like the best option. >> >> This discussion has gone quiet -- perhaps this represents preliminary consensus. >> >> Since VOTable 1.3 now appears to be on the cards, would it be useful >> for me to draft specific proposed replacement text for Section 3.5 >> (LINK Element) of the VOTable spec? > > An alternative approach is to address this in some place other than > the VOTable standard, for instance the relevant Theory or Semantics > or DM standard could prescribe that VOTables used in a particular > context should use the LINK attribute, and in particular its > content-role attribute, in such and such a way. Two thoughts on that: 1. One strand of this discussion is specific to VOTable in the sense that it's about a detail of VOTable syntax, the element; though one can imagine reusing the pattern in other syntactical contexts (for example suggesting a 'type' column in TAP metadata). Perhaps this strand is near-complete, inasmuch as the discussion quoted above suggests that IF this pattern is a good one, then LINK/@content-role is how it should be instantiated in VOTable. 2. The other strand is whether this is a good pattern, and I'd much rather that was discussed _outside_ the semantics group. Thus, if this present discussion starts to converge on a preliminary case, I'd like to move it to the votable list pretty promptly. That's because... > My personal feeling > is that if that could be made to work it would be a better way of > doing it, since it keeps VOTable as something more like a > content-neutral container with less semantic baggage, said baggage > being best dealt with in places where its scope and requirements > are better understood. [I admit though that the existing ucd and > utype attribures don't work this way]. ...the votable list is probably where the scope and requirements are best understood. If the discussion remains on the semantics list too long it'll be ghettoised. >> > > Couple of points occur to me: > First, is it not problematic that 'type' does not appear to be a > SKOS-specific term? If you were expecting to make SKOS-specific > usage of the href in question and it was being used to refer to > some (perhaps future) alternative semantic vocabulary with similar > syntax, might it not cause confusion? Applications need only process types they recognise, in the same way they now might process only UCDs and ignore utypes. There's a more wordy version of this explanation at the bottom. > I should admit that I am > deeply ignorant about what sort of thing SKOS might be, so I may > be making unnecessary difficulties here. > Second, "type" seems like rather an overloaded term, > but I'm happy to leave that choice of word to semantics people. There's less than meets the eye. Something like http://www.ivoa.net/rdf/Vocabularies/IAUT93#Quasars is a name, no more. Saying "this is a SKOS Concept" says "this is like a Library of Congress subject heading, and we suggest you use it accordingly". Once you find out more about this name, you discover that there are related names and labels. I don't imagine that's a name you would expect to find much in a VOTable, but one could imagine finding in a VOTable. I don't think Topcat would have much it could usefully do with that, but another application might be able to use this to provide units, say, or other consistency checks. Or the units might be retrieved from the URL. I'm suggesting overloading the term 'type' because (a) I don't think the overloading is problematic, and (b) because it would be good for this to be future-proof, and not confined to SKOS. Neither, by the way, is this confined to RDF: there's nothing in the proposal says that RDF should be returned from the URI, nor even that _anything_ should be returned, though obviously both would be reasonable behaviours. Perhaps dereferencing a URI could return an XML Registry entry? The suggestion is intended to be flexible enough that one could put a (URL form of a) UCD or a utype in the link/@content-role='type' element and it makes sense. I'm not proposing that (there are compatibility issues!), but I believe the system should be flexible enough to handle that. >> A small extra thing occurred to me. I would also suggest constraining >> link/@content-role elements to contain only roles described in the >> VOTable spec, with the exception of roles starting "x-", which can be >> prototyped freely. > > In general I like that pattern but (a) it ties the semantics of > that attribute to the VOTable standard, which as I say above I'm > not sure is the right place for it, and (b) it's not an idiom > which is used elsewhere in VOTable (if you exclude MIME types) > so I'd be a bit reluctant to introduce it here. That's reasonable. >> I'll also suggest a @content-role value of 'seealso', which can point >> to any other documentation, machine- or human-readable, about the thing >> containing the link element. > > Doesn't sound unreasonable, but it overlaps somewhat with the "doc" > value already suggested in the text. That's a sotto-voce/secondary suggestion, really. It's a sort of principled back-door (better: a 'loading bay') for anything else one may wish to say about the VOTable, absent the 'is-a' implication of the 'type' relationship. I could elaborate, but this message is too long already. Is the 'doc' value actually used by anyone? Come to think of it, the 'doc' relation could be overloaded as well, and forget about 'seealso'. Given , one could dereference http://example.org/foo/mytable in a browser and get HTML, or dereference the same URL using curl and retrieve any RDF (or whatever) that the table creator has provided. All the best, Norman ---- A longer version of the remark that "Applications need only process types they recognise", which I cut out of the main body of the email. Suppose (and this is NOT a proposal!) that VOTable decided to replace the @ucd and @utype attributes by a single @uthing attribute, which could somehow appear multiple times (like I said, not a proposal). Then you might have At present, applications will (I'm sure) process @ucd and @utype attributes with something like if attribute_exists('ucd'): if recognised_ucd(attribute_value('ucd')): process_ucd(attribute_value('ucd')) else if attribute_exists('utype'): if recognised__utype(attribute_value('utype') process_utype(attribute_value('utype')) fi That is, they presumably switch on the presence of the @ucd or @utype attribute, preferring one or the other. With the fantasy @uthing attribute, this would look like for uthing_string in attribute_values('uthing'): # or use this loop to find a preference between utypes and ucds uthing = lookup_ucd_or_utype(uthing_string) if uthing.is_utype(): process_utype(uthing.get_string()) else: process_ucd(uthing.get_string()) fi The application 'knows' what UCDs and utypes it can process, and knows that, say, 'pos.eq.ra;meta.main' is a UCD and not a utype. As long as there are no UCDs which are string-identical with utypes, there's no problem. The situation is exactly analogous to the (actual) proposal of a @content-role='type' link. An application might be able to process only a subset of the possible types, but it can recognise those types it can process, and can ignore the others (analogous to an application which can recognise UCDs but not utypes). -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From bthomas at noao.edu Fri Jun 1 06:37:03 2012 From: bthomas at noao.edu (Brian Thomas) Date: Fri, 01 Jun 2012 09:37:03 -0400 Subject: SKOS concepts in VOTable In-Reply-To: <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> Message-ID: <4FC8C57F.3060102@noao.edu> Hi All, Sorry to chime in at this late point in the discussion. I guess I don't understand why we need to invent something completely new to handle this situation. {apologies if someone already suggested the following and it was deemed unacceptable} Why aren't we considering simply importing parts of the RDF standard into VOTable schema? What about the "rdf:about" attribute into the VOTable standard? This would be unambigious in use (the rest of the world already defines and understands it), it could be made to allow for multiple semantic urls to be declared and it would conform to an existing standard and would be compatible with SKOS, as well as other forms of RDF like owl and because its namespaced, it would be trivial for downstream parsers to simply ignore it. For example ... .. Going further afield..I can see a case for allowing an import of "rdf:Description" elements as children as well and allowing the whole parts of an rdf document to be imported. For example, ... ... > ... Granted, that the last example is more challenging to for the machine to parse and grok...and we already have a time space coordinate definition, but you get the idea. My 2 cents, -brian On 06/01/2012 08:24 AM, Norman Gray wrote: > Mark and all, hello. > > On 2012 May 31, at 23:15, Mark Taylor wrote: > >> > On Thu, 31 May 2012, Norman Gray wrote: >> > >>> >> On 2012 May 28, at 10:54, Mark Taylor wrote: >>> >> >>>>> >>>> Solution 3 : >>>>> >>>> Use subelements for. >>>>> >>>> PROs : already allowed in VOTable 1.2. URIs can be expressed in href="". >>>>> >>>> Possible to use content-type and content-role attributes to give additional >>>>> >>>> context. Possible to have multiple for one. >>>>> >>>> CONs : not sure how parsers would handle this or how this can be used >>>>> >>>> in TAP... >>>> >>> >>>> >>> Since LINK is already present, and seems to be syntactically and >>>> >>> semantically capable of doing what's required here, it looks to me >>>> >>> like the best option. >>> >> >>> >> This discussion has gone quiet -- perhaps this represents preliminary consensus. >>> >> >>> >> Since VOTable 1.3 now appears to be on the cards, would it be useful >>> >> for me to draft specific proposed replacement text for Section 3.5 >>> >> (LINK Element) of the VOTable spec? >> > >> > An alternative approach is to address this in some place other than >> > the VOTable standard, for instance the relevant Theory or Semantics >> > or DM standard could prescribe that VOTables used in a particular >> > context should use the LINK attribute, and in particular its >> > content-role attribute, in such and such a way. From norman at astro.gla.ac.uk Fri Jun 1 07:18:01 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 1 Jun 2012 15:18:01 +0100 Subject: SKOS concepts in VOTable In-Reply-To: <4FC8C57F.3060102@noao.edu> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8C57F.3060102@noao.edu> Message-ID: <143C7041-81C8-4AA7-823C-4E61ADE3FE2A@astro.gla.ac.uk> Brian, hello. On 2012 Jun 1, at 14:37, Brian Thomas wrote: > Why aren't we considering simply importing parts of the RDF standard > into VOTable schema? What about the "rdf:about" attribute into the > VOTable standard? This would be unambigious in use (the rest of the > world already defines and understands it), it could be made to allow for > multiple semantic urls to be declared and it would conform to an existing > standard and would be compatible with SKOS, as well as other forms of > RDF like owl and because its namespaced, it would be trivial for downstream > parsers to simply ignore it. An interesting idea, but perhaps I'll let you try to sell that to the VOTable chair. Mark, you may want to stop reading about here... All the things you (Brian) say are true (one could also imagine a sort of VOTable RDFa), but: * The rdf:* elements look icky, and including them would require schema changes to avoid them breaking validation (which many people care about). That's not going to fly, because it was an explicit principle of the current forced changes in forthcoming 1.3, that this wouldn't be an opportunity to embark on wholesale VOTable revisions: the proposed changes to link/@content-role are only acceptable because they require no schema changes, and no more than a usage note added to the relevant section of the document. * Also, I think your proposed changes are too precise! There's been some pressure (mostly from the Theory IG) to get SKOS Concepts included somehow in VOTable, somewhere cognitively 'near' to utypes. I'd like to see something here which is flexible enough that could in principle (though I wouldn't expect in practice) support UCDs and utypes, too. Since UCDs, utypes and SKOS Concepts are all vague in different ways, the relationship between the LINK-annotated thing in the VOTable, and the 'type' is also necessarily vague, and the detailed semantics of the @content-role='type' link would be something like "has a type which is related to". That would handle all of the cases, plus references to owl:Class. This of course requires something more or less heuristic on the part of a reader, but that's no worse than the existing @ucd and @utype relationships, and at least we're up-front about it. In other messages I've mentioned the @content-role='seealso' (or @content-role='doc'). The reason for suggesting that is so that if it were deemed important to add some further semantic information, however precise, then this would point to a source of that: the retrieved seealso document could include statements about the VOTable document and id-bearing elements within it, without restriction. All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From dave.morris at bristol.ac.uk Fri Jun 1 07:52:14 2012 From: dave.morris at bristol.ac.uk (Dave Morris) Date: Fri, 01 Jun 2012 15:52:14 +0100 Subject: SKOS concepts in VOTable In-Reply-To: <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> Message-ID: <4FC8D71E.9070903@bristol.ac.uk> Hi all, This discussion looks very similar to one we had in the early days of VOSpace. The current suggestions ... iau93:Quasar ucd:src.redshift Both look fairly similar to the solution we adopted in VOSpace-1.0. http://www.ivoa.net/rdf/IAUT93#Quasar http://www.ivoa.net/rdf/UCD#src.redshift http://www.ivoa.net/myStandard/my-favourite-utype The key differences is that we avoided using a closed vocabulary for the @type attribute choosing instead to leave it open by defining it as 'anyURI' in the specification. The reasoning behind this was that if we used a closed vocabulary for the @type attribute, then adding new property types would require a new version of the specification. On the other hand, if we allowed an open vocabulary then we needed some way of making sure that the names were unique. By defining the @type attribute as anyURI, and stating in the specification that the URI should point to some form of descriptive resource we made it easy to add new types of properties while at the same time providing a mechanism for ensuring that the names were unique and a standard way of describing the types. So in the above example, the type='ivo://ivoa.net/semantics/core#ucd.rdf' attribute should resolve to a registry resource that says "the value of this property is a URL pointing to a RDF description of a UCD" For details of how the VOSpace properties are defined see http://www.ivoa.net/Documents/VOSpace/20111202/PR-VOSpace-2.0-20111202.html#sec3_2 Adopting this mechanism would require a change to the VOTable specification. * We could change the link at content-role to contain anyURI (old parsers may reject the new values) * We could add a new attribute e.g. link at content-type which would contain anyURI (old parsers may reject the new attributes) * We could add a new element, similar to, or adopting from, the VOSpace property (discussion of the xml schema would probably continue beyond 2019) If VOTable did adopt a similar URI based mechanism as VOSpace then we would be able to make use of the some of the same properties, property types and registered URIs in both the VOSpace and VOTable standards. Making such a move could be a significant step towards unifying the different mechanisms in use within the VO. Hope this helps, Dave On 06/01/2012 01:24 PM, Norman Gray wrote: > > Mark and all, hello. > > On 2012 May 31, at 23:15, Mark Taylor wrote: > >> On Thu, 31 May 2012, Norman Gray wrote: >> >>> On 2012 May 28, at 10:54, Mark Taylor wrote: >>> >>>>> Solution 3 : >>>>> Use subelements for . >>>>> PROs : already allowed in VOTable 1.2. URIs can be expressed in href="". >>>>> Possible to use content-type and content-role attributes to give additional >>>>> context. Possible to have multiple for one . >>>>> CONs : not sure how parsers would handle this or how this can be used >>>>> in TAP... >>>> >>>> Since LINK is already present, and seems to be syntactically and >>>> semantically capable of doing what's required here, it looks to me >>>> like the best option. >>> >>> This discussion has gone quiet -- perhaps this represents preliminary consensus. >>> >>> Since VOTable 1.3 now appears to be on the cards, would it be useful >>> for me to draft specific proposed replacement text for Section 3.5 >>> (LINK Element) of the VOTable spec? >> >> An alternative approach is to address this in some place other than >> the VOTable standard, for instance the relevant Theory or Semantics >> or DM standard could prescribe that VOTables used in a particular >> context should use the LINK attribute, and in particular its >> content-role attribute, in such and such a way. > > Two thoughts on that: > > 1. One strand of this discussion is specific to VOTable in the sense that it's about a detail of VOTable syntax, the element; though one can imagine reusing the pattern in other syntactical contexts (for example suggesting a 'type' column in TAP metadata). Perhaps this strand is near-complete, inasmuch as the discussion quoted above suggests that IF this pattern is a good one, then LINK/@content-role is how it should be instantiated in VOTable. > > 2. The other strand is whether this is a good pattern, and I'd much rather that was discussed _outside_ the semantics group. Thus, if this present discussion starts to converge on a preliminary case, I'd like to move it to the votable list pretty promptly. > > That's because... > >> My personal feeling >> is that if that could be made to work it would be a better way of >> doing it, since it keeps VOTable as something more like a >> content-neutral container with less semantic baggage, said baggage >> being best dealt with in places where its scope and requirements >> are better understood. [I admit though that the existing ucd and >> utype attribures don't work this way]. > > ...the votable list is probably where the scope and requirements are best understood. If the discussion remains on the semantics list too long it'll be ghettoised. > >>> >> >> Couple of points occur to me: >> First, is it not problematic that 'type' does not appear to be a >> SKOS-specific term? If you were expecting to make SKOS-specific >> usage of the href in question and it was being used to refer to >> some (perhaps future) alternative semantic vocabulary with similar >> syntax, might it not cause confusion? > > Applications need only process types they recognise, in the same way they now might process only UCDs and ignore utypes. There's a more wordy version of this explanation at the bottom. > >> I should admit that I am >> deeply ignorant about what sort of thing SKOS might be, so I may >> be making unnecessary difficulties here. >> Second, "type" seems like rather an overloaded term, >> but I'm happy to leave that choice of word to semantics people. > > There's less than meets the eye. > > Something like http://www.ivoa.net/rdf/Vocabularies/IAUT93#Quasars is a name, no more. Saying "this is a SKOS Concept" says "this is like a Library of Congress subject heading, and we suggest you use it accordingly". Once you find out more about this name, you discover that there are related names and labels. > > I don't imagine that's a name you would expect to find much in a VOTable, but one could imagine finding in a VOTable. I don't think Topcat would have much it could usefully do with that, but another application might be able to use this to provide units, say, or other consistency checks. Or the units might be retrieved from the URL. > > I'm suggesting overloading the term 'type' because (a) I don't think the overloading is problematic, and (b) because it would be good for this to be future-proof, and not confined to SKOS. Neither, by the way, is this confined to RDF: there's nothing in the proposal says that RDF should be returned from the URI, nor even that _anything_ should be returned, though obviously both would be reasonable behaviours. Perhaps dereferencing a URI could return an XML Registry entry? > > The suggestion is intended to be flexible enough that one could put a (URL form of a) UCD or a utype in the link/@content-role='type' element and it makes sense. I'm not proposing that (there are compatibility issues!), but I believe the system should be flexible enough to handle that. > >>> A small extra thing occurred to me. I would also suggest constraining >>> link/@content-role elements to contain only roles described in the >>> VOTable spec, with the exception of roles starting "x-", which can be >>> prototyped freely. >> >> In general I like that pattern but (a) it ties the semantics of >> that attribute to the VOTable standard, which as I say above I'm >> not sure is the right place for it, and (b) it's not an idiom >> which is used elsewhere in VOTable (if you exclude MIME types) >> so I'd be a bit reluctant to introduce it here. > > That's reasonable. > >>> I'll also suggest a @content-role value of 'seealso', which can point >>> to any other documentation, machine- or human-readable, about the thing >>> containing the link element. >> >> Doesn't sound unreasonable, but it overlaps somewhat with the "doc" >> value already suggested in the text. > > That's a sotto-voce/secondary suggestion, really. It's a sort of principled back-door (better: a 'loading bay') for anything else one may wish to say about the VOTable, absent the 'is-a' implication of the 'type' relationship. I could elaborate, but this message is too long already. > > Is the 'doc' value actually used by anyone? > > Come to think of it, the 'doc' relation could be overloaded as well, and forget about 'seealso'. Given , one could dereference http://example.org/foo/mytable in a browser and get HTML, or dereference the same URL using curl and retrieve any RDF (or whatever) that the table creator has provided. > > All the best, > > Norman > > > ---- > > A longer version of the remark that "Applications need only process types they recognise", which I cut out of the main body of the email. > > Suppose (and this is NOT a proposal!) that VOTable decided to replace the @ucd and @utype attributes by a single @uthing attribute, which could somehow appear multiple times (like I said, not a proposal). Then you might have > > uthing="pos.eq.ra;meta.main" > uthing="stc:AstroCoords.Position2D.Value2.C1" > .../> > > At present, applications will (I'm sure) process @ucd and @utype attributes with something like > > if attribute_exists('ucd'): > if recognised_ucd(attribute_value('ucd')): > process_ucd(attribute_value('ucd')) > else if attribute_exists('utype'): > if recognised__utype(attribute_value('utype') > process_utype(attribute_value('utype')) > fi > > That is, they presumably switch on the presence of the @ucd or @utype attribute, preferring one or the other. With the fantasy @uthing attribute, this would look like > > for uthing_string in attribute_values('uthing'): > # or use this loop to find a preference between utypes and ucds > uthing = lookup_ucd_or_utype(uthing_string) > if uthing.is_utype(): > process_utype(uthing.get_string()) > else: > process_ucd(uthing.get_string()) > fi > > The application 'knows' what UCDs and utypes it can process, and knows that, say, 'pos.eq.ra;meta.main' is a UCD and not a utype. As long as there are no UCDs which are string-identical with utypes, there's no problem. > > The situation is exactly analogous to the (actual) proposal of a @content-role='type' link. An application might be able to process only a subset of the possible types, but it can recognise those types it can process, and can ignore the others (analogous to an application which can recognise UCDs but not utypes). > From norman at astro.gla.ac.uk Fri Jun 1 09:31:22 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 1 Jun 2012 17:31:22 +0100 Subject: SKOS concepts in VOTable In-Reply-To: <4FC8D71E.9070903@bristol.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> Message-ID: <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> Dave, hello. Thanks for your comments. On 2012 Jun 1, at 15:52, Dave Morris wrote: > The current suggestions > > > > > > [...] > Both look fairly similar to the solution we adopted in VOSpace-1.0. > > > > http://www.ivoa.net/rdf/IAUT93#Quasar > http://www.ivoa.net/rdf/UCD#src.redshift > http://www.ivoa.net/myStandard/my-favourite-utype > > If I'm reading you correctly, I think the effective difference is that the @type attribute in property indicates a fine-grained relationship between the and the property value, whereas the only relationship in the VOTable LINK suggestion is the rather coarse relationship of 'this VOTable element has type...'. In both cases, there's no restriction on the vocabulary used -- LINK/@href can be anyURI. > For details of how the VOSpace properties are defined see > > http://www.ivoa.net/Documents/VOSpace/20111202/PR-VOSpace-2.0-20111202.html#sec3_2 Aha. I think I see the (slight) conceptual difference. The VOSpace property mechanism is for associating generic properties with nodes, so the role of the property/@type attribute is to say what the type of the relation is, quite generally (that is, it's a predicate, in RDF terms). The VOTable case is a more restricted one. Here, the only relationship we're discussing is the 'has type' relation which @content-role='type' creates, between the element containing the , and the value of LINK/@href. So yes, as you suggest, these two would become equivalent if LINK/@content-role were changed from NMTOKEN to anyURI. I broadly agree with you. The only downside I see with that is that it requires a schema change, which I think the VOTable WG are reluctant to countenance (though does anyone actually _use_ LINK/@content-role for anything? Would anyone even _notice_ a schema change here? (I suspect the answer to the second question is yes...)). All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From dave.morris at bristol.ac.uk Fri Jun 1 11:10:07 2012 From: dave.morris at bristol.ac.uk (Dave Morris) Date: Fri, 01 Jun 2012 19:10:07 +0100 Subject: SKOS concepts in VOTable In-Reply-To: <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> Message-ID: <4FC9057F.8030308@bristol.ac.uk> Hiya, On 06/01/2012 05:31 PM, Norman Gray wrote: > > So yes, as you suggest, these two would become equivalent if LINK/@content-role were changed from NMTOKEN to anyURI. > Yep, succinctly put :-) Changing LINK/@content-role from NMTOKEN to anyURI allows us to use the same URIs in both VOTable and VOSpace. The impact of the schema change would be that any existing strict VOTable parsers would reject content-role URIs that didn't fit in the existing NMTOKEN requirement, failing on the ':', '/' and '#' characters in the URI. Question is - is the gain in making the @type and @content-role attributes equivalent worth the side effects of the schema change. Dave From bthomas at noao.edu Fri Jun 1 18:38:48 2012 From: bthomas at noao.edu (Brian Thomas) Date: Fri, 01 Jun 2012 21:38:48 -0400 Subject: RDF Proposal (Was: Re: SKOS concepts in VOTable In-Reply-To: <143C7041-81C8-4AA7-823C-4E61ADE3FE2A@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <4FC8C57F.3060102@noao.edu> <143C7041-81C8-4AA7-823C-4E61ADE3FE2A@astro.gla.ac.uk> Message-ID: <7028121.K54gEBzQyU@silverfish> Hi Norman, All, I wanted to respond about your comments on the "RDF Proposal" I made earlier: On Friday, June 01, 2012 03:18:01 PM Norman Gray wrote: > > Brian, hello. > > On 2012 Jun 1, at 14:37, Brian Thomas wrote: > > > Why aren't we considering simply importing parts of the RDF standard > > into VOTable schema? What about the "rdf:about" attribute into the > > VOTable standard? This would be unambigious in use (the rest of the > > world already defines and understands it), it could be made to allow for > > multiple semantic urls to be declared and it would conform to an existing > > standard and would be compatible with SKOS, as well as other forms of > > RDF like owl and because its namespaced, it would be trivial for downstream > > parsers to simply ignore it. > > An interesting idea, but perhaps I'll let you try to sell that to the VOTable chair. > > Mark, you may want to stop reading about here... > > All the things you (Brian) say are true (one could also imagine a sort of VOTable RDFa), but: > > * The rdf:* elements look icky, and including them would require schema changes to avoid them > breaking validation (which many people care about). That's not going to fly, because it was an explicit > principle of the current forced changes in forthcoming 1.3, that this wouldn't be an opportunity to embark > on wholesale VOTable revisions: the proposed changes to link/@content-role are only acceptable > because they require no schema changes, and no more than a usage note added to the relevant > section of the document. > Icky?!? I suppose its "eye of the beholder" and all that. I like seeing namespaced stuff. Nevertheless, a personal standard of beauty is not an argument for or against using RDF (or namespaces on attributes). As for the breaking of validation on the schema, this is, of course true. This is, of course, not a unique feature of my proposal, I'll note that a few other proposals (even a new one today) also have this 'flaw'. But I think we are approaching this in the wrong manner. Here are some points which are bear repeating/raising and which bear upon this discussion: 1. Regardless of the mechanism chosen, I'll posit that semantic labelling is unlikely to be initially very popular with many sites/services in the IVOA. 2. We should be putting together (as has been called for by various persons already on this list) is a standard for semantic labelling which can span across more than the VOTable standard. This means any proposal must be orthogonal and separable from the existing standard which becomes "semantized". 3. Its already been pointed out that the existing VOTable standard is not going to be modified for the sake of semantics, and this has caused many on this list to do some serious mental gymnastics in order to retrofit the semantics into VOTable; none of which, I'll hazard, are particularly 'pretty' (heh). Under the weight of these points I'd then suggest that we pitch a new, hybrid, standard which *is* easily filtered back to the original standard and which uses a widely accepted semantic labelling mechanism which we can reuse beyond VOTable labelling. I believe that the RDF proposal is a reasonable basis for satisfying this. For example, we should be thinking not of shoe-horning semantics into VOTable 1.3, but instead positing a new standard, say "VOTable1.3s" which is the VOTable 1.3 standard + additional rdf:about attribue on field element. This proposed standard could then be used by the brave few services which serve out semantic data they can label their tables as such. Their feedback may indeed result in future refinements to the semantic labelling standard. Because the namespacing allows the semantic bits to be easily separable in the data by the client, or the server, the adoption is made easier by all concerned. Its rather trivial to make the output of the new service backward compatable to the original standard, as one can use any variety of technologies to filter out these semantic structures. As there is uptake for using semantic labelling, the VOTable folks may consider adding it to the cannonical standard at some future date, but until then, its probably a better idea to cut a provisional one to start. > * Also, I think your proposed changes are too precise! There's been some pressure (mostly from the Theory IG) > to get SKOS Concepts included somehow in VOTable, somewhere cognitively 'near' to utypes. I'd like to see s > omething here which is flexible enough that could in principle (though I wouldn't expect in practice) support UCDs > and utypes, too. Since UCDs, utypes and SKOS Concepts are all vague in different ways, the relationship > between the LINK-annotated thing in the VOTable, and the 'type' is also necessarily vague, and the detailed > semantics of the @content-role='type' link would be something like "has a type which is related to". That would > handle all of the cases, plus references to owl:Class. This of course requires something more or less heuristic > on the part of a reader, but that's no worse than the existing @ucd and @utype relationships, and at least we're > > up-front about it. Well I don't really understand this point. Use of rdf:about can point to a UCD, or other SKOS document (we can easily create, and bless, a SKOS version of the UCD standard). I see no reason we cannot point to utypes either. There is no intended scope other than the semantic target says something about the structure which contains it. The concepts pointed to may be orthogonal, or complementary, or otherwise. There is no restriction in this regard. Its up to the client to interpret their meaning which I dont think is particularly difficult. If I find that the rdf:about attribute has a utype, from the declared namespace I can know, "its a utype" which then the client reader is either setup to do something with, or, just as freely, to ignore. > > In other messages I've mentioned the @content-role='seealso' (or @content-role='doc'). The reason for suggesting > that is so that if it were deemed important to add some further semantic information, however precise, then this would > point to a source of that: the retrieved seealso document could include statements about the VOTable document and > id-bearing elements within it, without restriction. Perhaps the semantic structures, in various cases, should not be allowed in certain structures of the standard. Its true that one might desire to do this, for example, UCD is appropriate for "Field" in VOTable, less so for "TR". Then, again, its probably not appropriate to place *any* semantic labelling on TR in the first place (semantically uniform objects occur in columns of a table, not the rows), and the VOTable1.3s standard can certainly control which structures may have semantic labelling and which may not. Nevertheless, I believe this problem is solved by simply adopting *more* RDF into the standard. For example, rdf:Description element which I mentioned previously would allow you to semantically type the relationship to the target concept. Perhaps that is the better way to go. > > All the best, Same to you! Cheers, -brian > > Norman > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From norman at astro.gla.ac.uk Tue Jun 5 15:30:03 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 5 Jun 2012 23:30:03 +0100 Subject: SKOS concepts in VOTable (strawman proposal text for Sect 3.5) In-Reply-To: <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> Message-ID: <42404081-2285-416D-AAB1-65BE048AC496@astro.gla.ac.uk> Folks, On 2012 Jun 1, at 13:24, Norman Gray wrote: > 2. The other strand is whether this is a good pattern, and I'd much rather that was discussed _outside_ the semantics group. Thus, if this present discussion starts to converge on a preliminary case, I'd like to move it to the votable list pretty promptly. At the risk of being prematurely narrowing this discussion, can I propose some strawman text to replace Sect 3.5 of the VOTable standard . If we can turn this into something reasonable, we can propose it on the VOTable list. This is intended to take note of the various suggestions so far in this thread, with the exception of Brian's suggestion, which I've responded to separately. vvvvvvvv Strawman v1 VOTable Section 3.5, "LINK element" The LINK element provides pointers to other documents or data servers on the Internet through a URI. In VOTable, the LINK element may be part of a RESOURCE, TABLE, GROUP, FIELD or PARAM elements. The href attribute of the LINK element must contain a URI; this specification places no restrictions on the URI or what it returns, beyond the syntactical requirement that it be a valid URI. The gref attribute -- which refers to a linking protocol preferred by the initial versions of the VOTable specification [???GLU ref] -- is permitted but has been deprecated since version 1.1. NOTE: it is not a requirement that the URI can be successfully dereferenced, nor is it a requirement that what is returned when dereferencing a URI is unique (for example it is permissible for an origin server to return representations with different MIME types in response to different Accept headers in an HTTP request). Even when a URI is being used as a name rather than as a source of bytes, however, it is recommended that the URI be dereferenceable, producing documentation about the name. In the Astrores format, from which VOTable is derived, there are additional semantics for the LINK element: the href attribute is used as a template for creating URL's. This behavior is described for information in Appendix A.1. The LINK element has a name and ID, like many other elements in the VOTable specification. It may also have a content-role and a content-type attribute. The content-role attribute indicates the relationship between the element which contains the LINK element, and the resource named by the href attribute. There is no restriction on the values of the content-role attribute, but the following values are given meanings by this specification: doc: the URI is dereferenceable and provides documentation about the resource , where 'X' is the URI of the VOTable, and 'f' is the ID of the first containing element which has an ID attribute (that is, the attribute ancestor::*/@id[1], in XPath terms). The URI will also act as the Retrieval URI for the purposes of calculating a Base URI, in the sense of RFC 3986 Section 5.1. The URI may provide human- or machine-readable representations or both, depending on the retrieval mechanism (for example a URI might provide text/html content if it is retrieved through an HTTP URI with suitable Accept headers). type: the element containing this LINK element has a 'type-like' relationship to the resource named in the href attribute. If the href attribute names a SKOS Concept, for example, the containing element represents something which could be labelled by that Concept. This relationship requires a rather heuristic interpretation, by design; if more precise documentation is required, then this can be provided through a link with content-role='doc'. The URI may or might not be dereferenceable; if it is dereferenceable, it provides information about the URI itself, rather than the LINK element. Future versions of this specification may attach a meaning to other values of the content-role attribute, but will never define a role which starts with the string "x-". The content-type attribute provides a MIME type, which may indicate the type of the representation provided by the URI. Some protocols (for example HTTP) provide a mechanism for indicating the MIME type of the content being transported; in such a case, the MIME type in the response from the origin server overrides any MIME type indicated in the LINK element's content-type attribute. ^^^^^^^^ Version 1a might be the above, modified by Dave Morris's suggestion that the type of the content-role attribute should be xsd:anyURI. This implies a schema change, but the authors are not aware of any applications which will be affected by this in practice. The description of the meaning of the 'type' attribute is intentionally vague, so that it can include but isn't limited to SKOS Concepts. Does it sounds weirdly evasive rather than merely non-committal? I mention that this specification commits not to define roles starting "x-". Following Mark's comments on this, this avoids actually constraining values of this, but drops a strong hint about how to name experimental roles. As usual, I've lapsed into standards-ese. If this is too much at odds with the style of the rest of the document, we can lighten it up. All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From norman at astro.gla.ac.uk Tue Jun 5 15:30:05 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 5 Jun 2012 23:30:05 +0100 Subject: SKOS concepts in VOTable (example problems?) In-Reply-To: <4FC9057F.8030308@bristol.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> <4FC9057F.8030308@bristol.ac.uk> Message-ID: Dave and all, hello. On 2012 Jun 1, at 19:10, Dave Morris wrote: > Changing LINK/@content-role from NMTOKEN to anyURI allows us to use the > same URIs in both VOTable and VOSpace. I like this idea, partly because it's tidy, and partly because it harmonises the fairly extensive linked-data work of VOSpace with the very tentative linked-data experiment represented by this (still only potential) VOTable proposal. The problem is that it _does_ represent a schema change, and that's an argument that has yet to be really made. Such a change would probably have minimal effect -- possibly no practical effect at all -- but this not actually zero, so as you note, Dave, the question is whether the gain is worth any side-effects. One rather abstract payoff is flexibility; but flexibility to do what? The motivation for the present thread is that the Theory folk want to refer to SKOS Concepts within a distributed VOTable. This is to provide a form of 'type' relationship which goes beyond the specific cases of @ucd and @utype. One can imagine other annotations such as the writer (human or machine) of a VOTable, the date, and so on. Does anyone (Dave, Theory IG people, or others) have particular concrete use-cases or user-stories which might motivate a design here? We know we've got them, but it'd be good to assemble a manifest list of real-world examples? Hmm: I smell a wiki.... (It would appear that a element would support annotations for TABLE elements and some others. However: (i) there's no standardisation of the PARAM/@name fields, and (ii) this mixes up data and annotation/metadata.) All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From norman at astro.gla.ac.uk Tue Jun 5 15:30:21 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Tue, 5 Jun 2012 23:30:21 +0100 Subject: RDF Proposal (Was: Re: SKOS concepts in VOTable In-Reply-To: <7028121.K54gEBzQyU@silverfish> References: <4FBEFFFA.4020108@astro.unistra.fr> <4FC8C57F.3060102@noao.edu> <143C7041-81C8-4AA7-823C-4E61ADE3FE2A@astro.gla.ac.uk> <7028121.K54gEBzQyU@silverfish> Message-ID: <46E844B7-815D-4F23-B31C-52DF306EA3CF@astro.gla.ac.uk> Brian and all, hello. This is a rather discursive response -- it's thinking aloud. On 2012 Jun 2, at 02:38, Brian Thomas wrote: >> All the things you (Brian) say are true (one could also imagine a sort of VOTable RDFa), but: >> >> * The rdf:* elements look icky, and including them would require schema changes to avoid them >> breaking validation (which many people care about). That's not going to fly, because it was an explicit >> principle of the current forced changes in forthcoming 1.3, that this wouldn't be an opportunity to embark >> on wholesale VOTable revisions: the proposed changes to link/@content-role are only acceptable >> because they require no schema changes, and no more than a usage note added to the relevant >> section of the document. >> > > Icky?!? I suppose its "eye of the beholder" and all that. I like seeing namespaced stuff. Nevertheless, a personal > standard of beauty is not an argument for or against using RDF (or namespaces on attributes). > > As for the breaking of validation on the schema, this is, of course true. This is, of course, > not a unique feature of my proposal, I'll note that a few other proposals (even a new one today) > also have this 'flaw'. I've long been an enthusiast for the sort of 'mixin' extension mechanism which your proposal represents -- the idea of being able to add an rdf:Description element into an otherwise unrelated document instance, in a way which is invisible to a document processor which 'sees' VOTable (in this example) but ignores the unrecognised elements. I came across this first in HyTime, and it's never quite gone away (the wikipedia page at is opaque about the point of it, but illuminating about its legacy, which just about matches my experience of hacking my way through the gottverdamned standard). The problem with that is that you either (i) bake the extension elements into an extended schema, which loses the flexibility which was the original point, and annoys everyone who's depending on the original, and probably simpler, schema; or (ii) have a lot of fun-and-games and end up, as HyTime did, inventing a sort of rococo meta-schema mechanism which is intriguing and satisfying, but which is complicated enough that it's going to have ... major difficulty in the market of ideas; or (iii) abandon validation, and tell everyone "duck typing is good -- process what you recognise". Option (i) is all 'con' and no 'pro', and option (ii) is fun, but I eventually gave up even aspiring to sell it. I quite like option (iii), but no-one seems to agree with me. We're doomed. Or not: there's RDFa, which has the advantage of being more completely orthogonal to the *ML markup than HyTime ever managed to conceive of, and thus to evade some of the problems. Brian, were you thinking of RDFa when you were describing your earlier proposal? For those who aren't familiar with it, the idea of RDFa is that it's a smallish extension to the HTML DTD which allows one to embed a broad range of RDF statements into an HTML document. There's a good example in the Wikipedia article , but

This page was written by Norman.

...illustrates how it can intersperse normal HTML and RDF triples like "<> dc:creator 'Norman'." Now, RDFa is defined with respect to HTML, but there's no reason why one couldn't define an RDFa-like thing for VOTable, and the registry, and any other XML used in the IVOA. It would mean defining a couple of extra attributes in each of the relevant schemas, and mandating that they're ignored by existing applications. I think the result of that thought-experiment would look very similar to what you're proposing. So, onward to actually replying to your message. > 1. Regardless of the mechanism chosen, I'll posit that semantic labelling is unlikely to be initially very > popular with many sites/services in the IVOA. We -- and for the purposes of this screed I mean semantics at ivoa -- have failed to persuade many people of the advantages of this sort of approach. We're sure we've got the next XML here, but can't persuade people away from roff. Part of the resolution here is, I believe, a 'build it and they will come' attitude: we build systems which solve simple existing problems in a way which is thought-provoking and principled. The 'no schema changes' proposal for VOTable is I think such a thing, but that doesn't preclude thinking further into the future. > 2. We should be putting together (as has been called for by various persons already on > this list) is a standard for semantic labelling which can span across more than the VOTable standard. > This means any proposal must be orthogonal and separable from the existing standard which becomes > "semantized". > > 3. Its already been pointed out that the existing VOTable standard is not going to be modified for the > sake of semantics, and this has caused many on this list to do some serious mental gymnastics in order > to retrofit the semantics into VOTable; none of which, I'll hazard, are particularly 'pretty' (heh). I think it was S?bastien who initially proposed repurposing the LINK element, and I think that's inspired, because it solves a simple case of the problem in a way which is defensible in principle, and without gymnastics. You're maybe thinking of the vagueness of the 'type-like' relation implied by content-role='type'. It is vague, yes, but it's no _more_ vague than the UCD or utype relations which are already in use, so it's clearly not _unacceptably_ vague to VOTable users. Is it too vague to be a SemWeb solution? No: the linked data world has run up against such vagueness again and again ("what does owl:sameAs really _mean_?"), and the vagueness of the DC properties and the mutability of the FOAF ones, and they've just come to accept heuristics. The possibility of the LINK[@content-role='doc']/@href returning RDF could act as a back door^W^W loading bay for associating arbitrary extra triples with a VOTable in a way which is both precise, and completely ignorable for existing VOTable users. Your proposal, or an RDFa-style inflection of it, could be another. > Under the weight of these points I'd then suggest that we pitch a new, hybrid, standard which *is* easily > filtered back to the original standard and which uses a widely accepted semantic labelling mechanism > which we can reuse beyond VOTable labelling. VOTable is probably not going to change, but that needn't stop us using it as a skeleton on which to work out what such a mixin standard cum pattern would look like. If we can devise a set of patterns which solve real problems while using VOTable, it'd be clear how to extend them to other contexts, too. That'd need real problems to solve. I'm sure we can all come up with some more or less abstract ones -- "associate a writer and a data with a GROUP" -- but for the purposes of this exercise can we identify some manifestly concrete ones which people have run across? So, any offers? [Brian: I believe I've by now addressed the points you made following this quote -- have I missed anything major?] All the best, Norman [if you got down here, congratulations...] > -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From norman at astro.gla.ac.uk Wed Jun 6 04:08:12 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 6 Jun 2012 12:08:12 +0100 Subject: RDF Proposal (Was: Re: SKOS concepts in VOTable In-Reply-To: <46E844B7-815D-4F23-B31C-52DF306EA3CF@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <4FC8C57F.3060102@noao.edu> <143C7041-81C8-4AA7-823C-4E61ADE3FE2A@astro.gla.ac.uk> <7028121.K54gEBzQyU@silverfish> <46E844B7-815D-4F23-B31C-52DF306EA3CF@astro.gla.ac.uk> Message-ID: <21E40502-2907-4628-9815-B9564951DC3E@astro.gla.ac.uk> Greetings, all. On 2012 Jun 5, at 23:30, Norman Gray wrote: > For those who aren't familiar with it, the idea of RDFa is that it's a smallish extension to the HTML DTD which allows one to embed a broad range of RDF statements into an HTML document. There's a good example in the Wikipedia article , but > >

This page was > written by Norman.

> > ...illustrates how it can intersperse normal HTML and RDF triples like "<> dc:creator 'Norman'." > > Now, RDFa is defined with respect to HTML, but there's no reason why one couldn't define an RDFa-like thing for VOTable, and the registry, and any other XML used in the IVOA. It would mean defining a couple of extra attributes in each of the relevant schemas, and mandating that they're ignored by existing applications. I think the result of that thought-experiment would look very similar to what you're proposing. Actually, I've just tried this, and it works rather well. Below is a cropped version of one of the sample VOTables in the VOTable spec: Velocities and Distance estimations Distance of Galaxy, assuming H=75km/s/Mpc

010.68

+41.27

N 224

-297

0.7

Notice the addition of the extra namespaces, and the addition of various property, typeof, about, rel and href attributes. When I send this through a program which extracts RDF from RDFa (namely rapper from librdf.org, but there should be plenty others), I get: % rapper -irdfa -oturtle sample-votable-cropped.xml file:///Users/norman/Desktop/vo-rdfa/sample-votable-cropped.xml @base . @prefix rdf: . @prefix xsi: . @prefix : . @prefix stc: . @prefix dc: . @prefix phys: . @prefix ivoa: . <> dc:title "Velocities and Distance estimations" . <#col6> ivoa:hasSkosConcept ; dc:title "Distance of Galaxy, assuming H=75km/s/Mpc" ; a ivoa:DatabaseColumn . The "ivoa:" namespace is a fake one, but the others are real. Immediate problems are that RDFa [1,2] tends to be good about adding these annotations to existing information that's in the form of elements, but adding properties to existing attributes looks slightly more intricate. A theoretical problem is that RDFa is defined for XHTML, but I can see no reason why it wouldn't work in general for any other XML. The point of RDFa is that there are no _changes_ to the content of (in this case) the VOTable, but the extra attributes allow precise semantics to be overlaid on the information already present in the file. It's "principled screenscraping". Obviously, this is designed to be processed by being parsed into RDF, but there's no _requirement_ that RDF be the end-point, and an application could process these annotations in any way it wanted that was consistent with the RDFa semantics. So: do we have concrete examples of what it'd be good to do here? Can we find things we'd want to express, which can't be done this way? Does this seem to match what you were suggesting, Brian? All the best, Norman [1] RDFa Primer: http://www.w3.org/TR/xhtml-rdfa-primer/ [2] RDFa Syntax: http://www.w3.org/TR/rdfa-syntax/ -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From norman at astro.gla.ac.uk Wed Jun 6 06:56:53 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Wed, 6 Jun 2012 14:56:53 +0100 Subject: Fwd: RDF Proposal (Was: Re: SKOS concepts in VOTable References: <4FCF5A77.2020502@noao.edu> Message-ID: Reposting for Brian, who seems to be having trouble posting to the list.... Begin forwarded message: -------- Original Message -------- Subject: Re: RDF Proposal (Was: Re: SKOS concepts in VOTable Date: Wed, 06 Jun 2012 09:22:12 -0400 From: Brian Thomas To: IVOA semantics On 06/06/2012 07:08 AM, Norman Gray wrote: > Greetings, all. > > On 2012 Jun 5, at 23:30, Norman Gray wrote: > >> For those who aren't familiar with it, the idea of RDFa is that it's a smallish extension to the HTML DTD which allows one to embed a broad range of RDF statements into an HTML document. There's a good example in the Wikipedia article, but >> >>

This page was >> written byNorman.

>> >> ...illustrates how it can intersperse normal HTML and RDF triples like "<> dc:creator 'Norman'." >> >> Now, RDFa is defined with respect to HTML, but there's no reason why one couldn't define an RDFa-like thing for VOTable, and the registry, and any other XML used in the IVOA. It would mean defining a couple of extra attributes in each of the relevant schemas, and mandating that they're ignored by existing applications. I think the result of that thought-experiment would look very similar to what you're proposing. > Actually, I've just tried this, and it works rather well. > > Below is a cropped version of one of the sample VOTables in the VOTable spec: > > > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > xmlns="http://www.ivoa.net/xml/VOTable/v1.2" > xmlns:stc="http://www.ivoa.net/xml/STC/v1.30" > xmlns:dc="http://purl.org/dc/elements/1.1/" > xmlns:skos="http://www.w3.org/2004/02/skos/core#" > xmlns:phys="http://purl.org/astronomy/vocab/PhysicalQuantities/" > xmlns:ivoa='http://purl.org/astronomy/vocab/XXXivoa-relations/'> > > > Velocities and Distance estimations > unit="m" value="3.6"/> > datatype="float" width="4" precision="1" unit="Mpc" > typeof="ivoa:DatabaseColumn" about='#col6'> > rel='ivoa:hasSkosConcept' href='phys:Distance' > >Distance of Galaxy, assuming H=75km/s/Mpc > > > > > > > > >

010.68

+41.27

N 224

-297

0.7

This page was >> written byNorman.

010.68

+41.27

N 224

-297

0.7

> > > > Notice the addition of the extra namespaces, and the addition of various property, typeof, about, rel and href attributes. When I send this through a program which extracts RDF from RDFa (namely rapper from librdf.org, but there should be plenty others), I get: > > % rapper -irdfa -oturtle sample-votable-cropped.xml file:///Users/norman/Desktop/vo-rdfa/sample-votable-cropped.xml > @base . > @prefix rdf: . > @prefix xsi: . > @prefix : . > @prefix stc: . > @prefix dc: . > @prefix phys: . > @prefix ivoa: . > > <> > dc:title "Velocities and Distance estimations" . > > <#col6> > ivoa:hasSkosConcept ; > dc:title "Distance of Galaxy, assuming H=75km/s/Mpc" ; > a ivoa:DatabaseColumn . > > > The "ivoa:" namespace is a fake one, but the others are real. > > Immediate problems are that RDFa [1,2] tends to be good about adding these annotations to existing information that's in the form of elements, but adding properties to existing attributes looks slightly more intricate. A theoretical problem is that RDFa is defined for XHTML, but I can see no reason why it wouldn't work in general for any other XML. > > The point of RDFa is that there are no _changes_ to the content of (in this case) the VOTable, but the extra attributes allow precise semantics to be overlaid on the information already present in the file. It's "principled screenscraping". > > Obviously, this is designed to be processed by being parsed into RDF, but there's no _requirement_ that RDF be the end-point, and an application could process these annotations in any way it wanted that was consistent with the RDFa semantics. > > So: do we have concrete examples of what it'd be good to do here? Can we find things we'd want to express, which can't be done this way? Does this seem to match what you were suggesting, Brian? Yes, more or less. I honestly had'nt thought of RDFa per se, I was simply shooting for embedding some portion of RDF into an XML document. But what you outline appears to be very compatible in spirit, and I think your ideas are an improvement on my proposal. I only worry about implementing *all* of the RDFa standard. Based on the use cases we can gather, I would suggest we endorse using only a portion of the standard to start so as to not scare off our potential suitors in other areas of the IVOA. Perhaps that fear of mine is overblown; I certainly have no technical reasons for avoiding adoption of all of RDFa and the bits you have above are pretty simple and cover quite a lot of possible cases. I'll end by noting that your suggestion above also appears to require a schema change ;) One difference to your proposal I might try, is to namespace the new attributes so that they are easily dropped by an XSLT script to revert the document back to its canonical form. For example, changes in this regard to your above document would be: xmlns:s="http://www.ivoa.net/xml/semanticMarkup/v1.0" Distance of Galaxy, assuming H=75km/s/Mpc But filtering with a very simple XSLT script would return the document to its 'non-semantic' state (where it may be validated by the canon schema) Cheers, -brian > > All the best, > > Norman > > [1] RDFa Primer: http://www.w3.org/TR/xhtml-rdfa-primer/ > [2] RDFa Syntax: http://www.w3.org/TR/rdfa-syntax/ > > From dave.morris at bristol.ac.uk Fri Jun 8 08:02:08 2012 From: dave.morris at bristol.ac.uk (Dave Morris) Date: Fri, 08 Jun 2012 16:02:08 +0100 Subject: SKOS concepts in VOTable (example problems?) In-Reply-To: References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> <4FC9057F.8030308@bristol.ac.uk> Message-ID: <4FD213F0.6000203@bristol.ac.uk> On 06/05/2012 11:30 PM, Norman Gray wrote: > > Does anyone (Dave, Theory IG people, or others) have particular concrete use-cases or user-stories which might motivate a design here? We know we've got them, but it'd be good to assemble a manifest list of real-world examples? Hmm: I smell a wiki.... > The use-case for using URIs is that it provides a discovery mechanism for new types. If we use NMTOKEN, and I encounter this in a VOTable then there is no obvious way for me to discover what an 'x-experimental-021' link means. On the other hand, if we use anyURI and I encounter this then the URI 'ivo://org.astrogrid/research/experimental-021' should resolve to a registry resource that describes what an 'experimental-021' link means. Note - the URI doesn't *have* to resolve, but if it does resolve to a resource, then that resource *should* describe the link role. Hope this helps, Dave From norman at astro.gla.ac.uk Fri Jun 8 08:44:00 2012 From: norman at astro.gla.ac.uk (Norman Gray) Date: Fri, 8 Jun 2012 16:44:00 +0100 Subject: SKOS concepts in VOTable (example problems?) In-Reply-To: <4FD213F0.6000203@bristol.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> <4FC9057F.8030308@bristol.ac.uk> <4FD213F0.6000203@bristol.ac.uk> Message-ID: <1319C5E3-B457-4873-8C8C-C890E01AF744@astro.gla.ac.uk> Dave, hello. On 2012 Jun 8, at 16:02, Dave Morris wrote: > On 06/05/2012 11:30 PM, Norman Gray wrote: >> >> Does anyone (Dave, Theory IG people, or others) have particular concrete use-cases or user-stories which might motivate a design here? We know we've got them, but it'd be good to assemble a manifest list of real-world examples? Hmm: I smell a wiki.... [...] > On the other hand, if we use anyURI and I encounter this > > > > then the URI > > 'ivo://org.astrogrid/research/experimental-021' > > should resolve to a registry resource that describes what an 'experimental-021' link means. Sure -- that's the general argument for using URIs as roles here. I certainly subscribe to that, and have banged on about it in various places (though as you know I'm no fan of ivo: URIs). What I was meaning was more specifically problems where (for example) data centres want to include some metadata in a VOTable, can't find a way to do so, perhaps because of the limitations of the VOTable data model or UCDs, but could do so if they were allowed to define a content-role in this open-ended way. We know that the VOTheory group have a desire to include SKOS Concepts in VOTables, and specifying a @content-role='type' arguably addresses that concrete problem (and appears to be pushing at an at-least unlocked door for VOTable). Obviously, this isn't a general solution, but a 'generalisability' argument has a lot less traction on the VOTable list than it has here. Myself, I don't think it's a great idea to solve only the problems you know you have, but that approach does have the considerable advantage of... well, getting ahead and actually solving the problems you know you have. That approach is in vogue on the VOTable list, so if this proposal is heading there, that's the kind of argument we'd have to present. So: What are the metadata problems that datacentres and scientists have that can be solved by either the anyURI @content-role or the more generic RDFa-style solution that Brian and I were discussing? All the best, Norman -- Norman Gray : http://nxg.me.uk SUPA School of Physics and Astronomy, University of Glasgow, UK From dave.morris at bristol.ac.uk Fri Jun 8 09:39:40 2012 From: dave.morris at bristol.ac.uk (Dave Morris) Date: Fri, 08 Jun 2012 17:39:40 +0100 Subject: SKOS concepts in VOTable (example problems?) In-Reply-To: <1319C5E3-B457-4873-8C8C-C890E01AF744@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <4FC8D71E.9070903@bristol.ac.uk> <86CC5B55-9963-460D-A4CA-B2D12293B193@astro.gla.ac.uk> <4FC9057F.8030308@bristol.ac.uk> <4FD213F0.6000203@bristol.ac.uk> <1319C5E3-B457-4873-8C8C-C890E01AF744@astro.gla.ac.uk> Message-ID: <4FD22ACC.9050604@bristol.ac.uk> On 06/08/2012 04:44 PM, Norman Gray wrote: > > So: What are the metadata problems that datacentres and scientists have that can be solved by either the anyURI @content-role or the more generic RDFa-style solution that Brian and I were discussing? > If a datacentre wants to publish VOTables with links to a new type of metadata, then the current NMTOKEN value is fine, and the x-prefix provides a way for them to add new @content-role values when they need to. The only thing it doesn't do is provide a discovery mechanism. The problem anyURI addresses is with the scientist who receives a VOTable which contains an unknown @content-role. Specifically : How does a scientist find out what 'x-experimental-021' means ? How does the datacenter tell everyone about their new 'x-experimental-021' links and how to use them ? If the experimental link type is adopted by the IVOA, how do we tell everyone that 'x-experimental-021' is now called 'ivo-range-info' ? AnyURI just provides a discovery mechanism, nothing more. Hope this helps, Dave From dave.morris at bristol.ac.uk Fri Jun 8 11:06:50 2012 From: dave.morris at bristol.ac.uk (Dave Morris) Date: Fri, 08 Jun 2012 19:06:50 +0100 Subject: SKOS concepts in VOTable (strawman proposal text for Sect 3.5) In-Reply-To: <42404081-2285-416D-AAB1-65BE048AC496@astro.gla.ac.uk> References: <4FBEFFFA.4020108@astro.unistra.fr> <23C2F024-4B34-4BD8-96C6-211A51DB9593@astro.gla.ac.uk> <9207B54A-1262-4485-9220-28381C51938D@astro.gla.ac.uk> <42404081-2285-416D-AAB1-65BE048AC496@astro.gla.ac.uk> Message-ID: <4FD23F3A.1010005@bristol.ac.uk> On 06/05/2012 11:30 PM, Norman Gray wrote: > doc: the URI is dereferenceable and provides documentation about the resource .... > type: the element containing this LINK element has a 'type-like' relationship to the .... Having two different ways of describing which element the contents of the link applies to is confusing. ---- ---- > doc: the URI is dereferenceable and provides documentation about the resource , where 'X' is the URI of the VOTable, and 'f' is the ID of the first containing element which has an ID attribute (that is, the attribute ancestor::*/@id[1], in XPath terms). The URI will also act as the Retrieval URI for the purposes of calculating a Base URI, in the sense of RFC 3986 Section 5.1. The URI may provide human- or machine-readable representations or both, depending on the retrieval mechanism (for example a URI might provide text/html content if it is retrieved through an HTTP URI with suitable Accept headers). The description for 'doc' refers to two different URIs as 'the URI' which means it is not clear which URI the last sentence is referring to, the URI or the @href URI. I'm probably reading it wrong, but in this example

then because the table element has an @id attribute and the field element doesn't, does the document pointed to by the link @href provide documentation about the table, not the field ? Perhaps an examples might make it clearer ? ---- ---- > type: the element containing this LINK element has a 'type-like' relationship to the resource named in the href attribute. If the href attribute names a SKOS Concept, for example, the containing element represents something which could be labelled by that Concept. This relationship requires a rather heuristic interpretation, by design; if more precise documentation is required, then this can be provided through a link with content-role='doc'. The URI may or might not be dereferenceable; if it is dereferenceable, it provides information about the URI itself, rather than the LINK element. Again, perhaps some examples might make this clearer. How about : If content-role is 'type', then the link @href URI is a name for a type-like concept which applies to the element containing the element. In the following example, the URI 'dc:creator' is a name for a semantic type that applies to the enclosing element. If the link @href is dereferenceable, then it provides information about the type the @href is naming, rather than the element containing the link. In the following example, the URI 'http://purl.org/dc/elements/1.1/creator' resolves to resource that describes the semantic type that applies to the enclosing element, not the element itself. ---- ---- Hope this helps, Dave From m.b.taylor at bristol.ac.uk Tue Jun 19 13:56:07 2012 From: m.b.taylor at bristol.ac.uk (Mark Taylor) Date: Tue, 19 Jun 2012 21:56:07 +0100 (BST) Subject: VOUnits 1.0 revised version In-Reply-To: <4FBB21D3.6030009@astro.unistra.fr> References: <4FBB21D3.6030009@astro.unistra.fr> Message-ID: On Tue, 22 May 2012, Sebastien Derriere wrote: > Hello all, > > Here is a revised version of the VOUnits 1.0 document, following comments > received on the previous version and gathered on the wiki, as well as > discussions in the interop session in Urbana : > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DiscussionOnVOUnits > The document will be also uploaded in the ivoa doc repository. > > Changes are listed in the Annex A. The main change is to accomodate > possible numerical prefixes to have VOUnits like "2.54 cm". > Most of the proposal is still very close to the FITS 2010 paper. > The proposed roadmap is to have two weeks for discussion on the semantics > mailing list or on the wiki page, before moving to PR and opening the > official RFC. Hi Sebastien et al., Here are a few comments on the VOUnits document (May 22 Draft). Mostly these are pretty minor, on the whole it looks good. Sec 1.2: I'm not quite sure what the distinction, if any, is supposed to be between "symbol"/"sym" and "label". Sec 1.3: "and be as compliant..." -> "and will be as compliant..." Sec 2.5: IAU 2000 is referenced in the text, but not in the References (though IAU 1989 is in the References). Section 3: References to "Tab. n" in the tables confused me to start with - I think it means the tables in the relevant external documents. It's valuable to have these tables in their existing compact form, but a bit of explanation about the format before the first one might improve clarity. Table 2: I don't quite understand the bottom part of the first (largest) row of this table, i.e. the part below "rad, sr". Is it additional notes/deviations from what's in the rest of that row? Why is the VOUnits part blank? Some annotation in the first column there could clarify. Table 3: Formatting - the line "da, h, k, ..., E" should be directly below "d, c, m, ... a"? Currently there's a gap between them. Final column, penultimate row: "P" has wrong font in "all (except P for a)". Table 4: One usage of "uarcsec" has wrong font. Should "jansky" have a capital J? Section 3.5: Usage of an empty string for "no unit". Is this supposed to be as distinct from the absence of a unit string (e.g. unit="" as opposed to no unit attribute in VOTable FIELD)? If so I doubt that it will work well, since different scenarios may or may not provide the option of a null-like value for units. If the intention is just to make it clear that you don't write explicitly "unitless" or something like that, it sounds fine, but it would be worth noting exactly what's meant here. Table 3.6: s/asterix/asterisk/g "MUST never two" - some missing text? Section 3.7: "simple or double quotes" - should that be "single or double quotes"? Acknowledgements: "proving comments" -> "providing comments"? Mark -- Mark Taylor Astronomical Programmer Physics, Bristol University, UK m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/