Re: regrets and a new spin on contexts

On Apr 25, 2012, at 12:32 PM, Sandro Hawke wrote:

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

And I see the main value of the idea as providing a simple, effective way to short-circuit such useless debate. When you find you want to extend or restrict an already used meaning in this kind of a way, make a new, um, context, inherit the old one, state your intended changes in meaning, then use your new context to publish your stuff and loudly advertise it, telling your community (if you have one) to use it consistently in your specified way. Then bob's your uncle, and the global old meanings are still around and not corrupted by your peculiarities,. This is about as much effort as modifying a website, and because it is so easy, people will do it, and committees will spend less time debating. (Well, maybe not, but it will be less important.) 

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

Well, as I say, you can think of this whole thing as a kind of earthbound version of owl:imports, where you can 'import' not just a graph, but a whole specification of a vocabulary and what it means, using any way of specifying you want. The more loosey-goosey you are about the specification, the less useful you might be, but sometimes a quick dirty trick is just what is needed to get things started. You can always tidy it up later. 

Pat


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

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Sunday, 29 April 2012 04:11:24 UTC