- From: Pat Hayes <phayes@ihmc.us>
- Date: Mon, 30 Apr 2012 00:07:58 -0500
- To: Thomas Baker <tom@tombaker.org>
- Cc: W3C RDF WG <public-rdf-wg@w3.org>
On Apr 29, 2012, at 2:10 AM, Thomas Baker wrote: > On Sat, Apr 28, 2012 at 10:52:34PM -0500, Pat Hayes wrote: >> Thanks for the interesting examples. Yes, this is exactly what I had in mind. >> I am sure that this kind of thing will continue to happen, and it might be >> good to provide a mechanism to allow it to be organized using Web methods >> rather than kind of ignored or treated as Bad Practice. BTW, it happens off >> the Web, as well, in any reasonably large-scale (say, 4-5 man-years and up) >> ontology project. It happened all the time in Cyc, and adopting the context >> meachanism was crucial in overcoming the resulting problems. >> >> Regarding the terminology, I really have no axe to grind for "sematnic >> extension" other than it is already in the 2004 RDF specs, so it seemed like >> less of a reach to suggest making it explicoit under that name. I actually >> prefer the original "context" terminology. But if people prefer something >> else altogether, Im cool with whatever we call it. > > It seems we are picturing the same thing. But if so, then I have a problem > with calling the property "rdf:inherits" and, for the same reasons but less > strongly, with calling them "contexts". To me, both terms (but especially > "inherits") evoke computer programming terminology in unhelpful ways. Ah. Coming from a different tradition, I probably missed the associations which are bothering you. So let us seek for a less worrying terminology, by all means. > > What bothers me about "contexts" is that it could be taken to mean that the > meaning of an IRI depends on context. I would not want the notion to be taken > as a license to violate the global context in a local context (think: global > variables and local variables). But that is exactly what it does provide. We may regret this, but it does provide this, um, licence. And this is exactly what Antoine (and others) want to have, as I understand it. > Rather, what we're doing is acknowledging that people "see" or "interpret" IRIs > through particular lenses. What is the difference between a view through a lens and a change of context? Would there be any entailments that hold under one but not the other? > In terms of message, the act of "seeing" or > "interpreting" an object does not imply that the object that everyone sees is > actually being transformed. Hmm. So for example (trying to understand here....) "seeing" carbon as a mixture of isotopes rather than a single element is a different lens 'view' of the same real thing. Or taking 'person' to mean 'american person' is a kind of zoom lens. Yes, that is an attractive analogy, indeed. > Maybe something along the lines of "RDF > Interpretations" or "RDF Lenses"? Not "interpretation" (the semantics has already used that one) but how about "view" ? Or "perspective"?? Or "angle" ??? Then the 'inherits' property could be called rdf:inView or just rdf:view or rdf:scope (as in telescope or microscope.) In fact, we could call them 'rdf scopes', it occurs to me: scope noun 1 the extent of the area or subject matter that something deals with or to which it is relevant. 2 the opportunity or possibility to do or deal with something. • archaic a purpose, end, or intention. 3 informal, a telescope, microscope, or other device having a name ending in -scope. -scope comb. form denoting an instrument for observing, viewing or examining. > > Then if the range of rdf:inherits does indeed include things like 100 pages of > plain-text explanation, we should avoid implying that these interpretations are > by definition importable and applicable in some sort of automatic, > machine-processable way. Absolutely. The automatic part can range from a minimum of a licence to merge graphs without further checking (this *ought* to be automatic, but it does no harm to make it explicit) through using a specialized inference process identified with the context (eg for the FOAF owl:sameAs + owl:FunctionalProperty combination) all the way up to a complete imported RDF graph containing, say, an OWL ontology.. Pat > The name should leave no doubt that this is a > documentation property. Maybe something along the lines of or > "rdf:interpretedUsing" or "rdf:lens"? > > Tom > > > >> >> Pat >> >> >> On Apr 25, 2012, at 12:00 PM, 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 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> >>> >>> >> >> ------------------------------------------------------------ >> 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 >> >> >> >> >> > > -- > Tom Baker <tom@tombaker.org> > > ------------------------------------------------------------ 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 Monday, 30 April 2012 05:08:33 UTC