On May 30, 2007, at 7:11 AM, Alan Ruttenberg wrote:
I think there are two dimensions:
1) Allowing annotation properties to have subproperties so, e.g.
that skos:prefLabel and skos:altLabel can be subproperties of
rdfs:label.
Mostly this is addressed by punning in 1.1 but there are still
annotation property leftovers like rdfs:label and rdfs:comment or
any other property where one doesn't want to make a commitment as
to whether they are datatype or object.
We at manchester have been discussing the annotation system for
several months. Boris and Bernardo crystalized one strand of our
thinking in an ISWC paper. It's like punning except 1) you project
the entities into a separate domain, i.e., imagine that instead of
one document which holds abox assertions about classes and properties
as well as individuals, you have two, one for classes and properties
and one for individuals and 2) you have another box for axoms. A
language like SPARQL can seamlessly query across these documents, so
all the system need to do is automatically keep em in synch. This
makes mixed tbox and abox queries pretty straightforward as well.
Thus, you can reserve punning (or some other higher order features)
in the "domain part" of the ontology for representing *domain* features.
(What started this whole line off was my concern about the
indiscriminate mixing *annotation* modeling and domain (higher-order)
modeling...you can get some very weird and hard to track down
effects. While punning doesn't let you get "direct" entailments
between levels, i.e., just because C is *equal* to B doesn't mean
that C (as a class) is *equivalent* to D, as it would be in Hilog and
OWL Full), you can get indirect ones, e.g., through fixing the size
of the domain, or of a class.)
2) Some sort of easy tagging mechanism for labels - perhaps
something along the lines of the language tags. The case is that
one ontology is used by a variety of communities (proteomics, flow
cytometry, enzymology) each of which has preferred labels for some
of the terms, and it would be nice to have some global switch to
select which view you wanted to see.
So, you can do this in line or out of line. Out of line solutions
include things like Fresnel which have a selector/view language which
let you develop "informational" style sheets. There are several
Fresnel viewers and toolkits out there (we were using it in JSpace).
It also allows you to do some presentation, e.g., ordering. The plus
side is that you don't have to touch the ontology itself. The
downside is that the sheet can get out of synch with practice.
Inline can be done in an icky or non-icky manner. Icky would be to
have distinct properties and duplicate common information, perhaps
getting fall back behavior through property inheritance (I *said* it
was icky!). Non icky would be, as you say, tags.
btw, couldn't easily tell from the 1.1 spec whether one can add
annotations to labels (like this tag thing).
Only in an icky or semi-icky manner at the moment, I believe. The
semi-icky would be to make a label individual with two properties,
tag and value. Indeed, that would *have* to be the case in the RDF
serialization, I think.
The functional syntax and XML syntax can easily be extended to add a
tag "slot" to annotations (instead of having to nest it with a label
object). I *suppose* in RDF you could try to overload the lang
tag...oh...you could also make datatypes which had no other purpose
but to be the tag.
Hope this helps.
Cheers,
Bijan.
