Re: regrets and a new spin on contexts

On Wed, 2012-04-25 at 18:00 +0100, Thomas Baker wrote:
> 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 the original Semantic Web vision, they would have defined and used a
Composer subclass.  Of course, that wouldn't actually work, because they
couldn't count on anyone (either during data publication or data
consumption) to do inference.

> 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.

In theory, the advice should be: make your own vocabulary and use OWL to
tie it to other well known vocabularies. 

Except, as above, since people aren't doing inference, this wont work.

[ Maybe I need to blog: Why The Semantic Web Hasn't Taken Off:  1.
Data-consuming software doesn't reliably do inference.  2.  Vocabulary
IRIs don't reliably lead to great documentation.   ....   What else? ]

> 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"?

How about "ontologies"?     

I'm amused, but I'm also 100% serious.   An ontology is a set of
constraints on the meanings of terms.   In some cases, OWL might not be
the right language to express the ontology -- in some cases, we need 100
pages of natural language prose.   It's still an ontology.

    -- Sandro


> 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
> 
>

Received on Wednesday, 25 April 2012 17:32:40 UTC