RDF Proposal (Was: Re: SKOS concepts in VOTable

[Brian Thomas]

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: <http://www.ivoa.net/pipermail/semantics/attachments/20120601/d7fb5813/attachment-0001.html>