Re: regrets and a new spin on contexts

On Mon, Apr 23, 2012 at 12:45:31AM -0700, Pat Hayes wrote:
> Second, I have written up essentially the same proposal in a slightly
> different terminology which might (?) be more palatable, anyway it is there
> for inspection at http://www.w3.org/2011/rdf-wg/wiki/AnotherSpin

I like this proposal.  Let me test my understanding of it with reference to
some examples "from the wild":

1) As an example of "a named public agreement to use a particular vocabulary of
   IRIs... with a particular meaning" consider "Dublin Core in OWL 2" [1] -- an
   interpretation of DCMI Metadata Terms undertaken completely independently of
   DCMI which offers Turtle and RDF/XML for an "annotation property
   version" [2] and an "object and datatype property version" [3] of DCMI's
   /terms/ vocabulary, e.g.:

    dcterms:dateCopyrighted a owl:AnnotationProperty ;
        rdfs:label "Date Copyrighted"@en-us ;
        skos:definition "Date of copyright."@en-us ;
        rdfs:subPropertyOf dcterms:date ;
        rdfs:range rdfs:Literal .

2) Again from the Dublin Core context, an example of what Pat calls 
   "informally expressed descriptions of constraints":  When the notion of
   Application Profile entered DC discourse in 2000, it came to be seen as a
   construct which, by definition, only "re-used" terms coined elsewhere (i.e.,
   in vocabularies, or "element sets", as they were called).  The purpose of an
   Application Profile was to document how a particular application or
   community used terms from different vocabularies to meet particular
   descriptive requirements.  But what alot of people wanted to do, it turned out,
   was to say: "We're using DC Creator, but we're using it specifically for
   Composers."  There was alot of discussion to the effect that yes, you can
   re-label dc:creator "Composer", but that that does nothing to change the
   global meaning of the property.

In both the formal "DC-in-OWL2" case and in many of the less formal
"application profile" cases, the authors of these "semantic extensions" (in
Pat's sense) replicated definitional information from DCMI's documentation --
as in the example above -- presumably in order simply to present self-contained
documentation.  There was some discussion to the effect that it would be more
elegant (and in principle more maintainable) if the documentation were layered,
such that annotations would simply be added to the "canonical" definitional
information imported directly from DCMI, but nobody came forward with a
convincing method for doing this in practice.

Alot of people said they wanted to "extend" Dublin Core, but what this often
meant, in practice, was that they wanted to coin more properties.  The notion
that application profiles should carefully avoid "extending" existing DC
properties semantically was part of this discussion.

My point is that these issues basically bubbled up, and they pointed at deeper
questions about whether vocabulary owners really do have as much control over
the interpretation of their IRIs as we believe they should have in order for
the global hypothesis to work in practice.  Even if we don't exactly want to
encourage people to make "extensions", it is a good thing to give them a name
because this is something that people do.  "Allow[ing] users to be explicit
about which semantic assumptions they wish to inherit in their RDF assertions"
is a step in the right direction.

However, I do not like calling these things "semantic extensions".  Pat talks
about imposing additional "conditions" or "constraints" on the interpretation
of IRIs.  To me, "limiting" and "constraining" are the opposite of "extending".
As in the DC discussion ten years ago, the word "extension" hints at things
quite different from limiting and constraining (like coining new IRIs).  If the
intended scope of "semantic extensions of RDF" is the interpretation of
existing IRIs, could we call them something like "semantic annotations" or
perhaps "semantic clarifications"?

Tom

[1] http://bloody-byte.net/rdf/dc_owl2dl/index.html
[2] http://purl.org/NET/dc_owl2dl/terms
[3] http://purl.org/NET/dc_owl2dl/terms_od


-- 
Tom Baker <tom@tombaker.org>

Received on Wednesday, 25 April 2012 17:00:48 UTC