- From: Niklas Lindström <lindstream@gmail.com>
- Date: Thu, 21 Jul 2011 17:58:37 +0200
- To: Gregg Kellogg <gregg@kellogg-assoc.com>
- Cc: public-rdfa-wg <public-rdfa-wg@w3.org>
Hi Gregg! 2011/7/20 Gregg Kellogg <gregg@kellogg-assoc.com>: > Interesting ideas. I think the proxy vocabulary addresses a number of problems that even appear in ontology creation. For example, the recently published (CR) Ontology for Media Resources [1] defines local versions of properties, such as ma:title and ma:date, which are really just the same as dc:label and dc:date, to name a few. As with other ontology authors, and for authors considering the use of RDFa @vocab, the advantages of having a monolithic vocabulary often out-weigh the more "correct" mixin re-use of other vocabularies; OpenGraph and schema.org is only the most obvious (and visible) examples of this. I'm glad you think so! It's exactly what I had in mind. I definitely see potential in standardizing this pattern (with a map/proxy vocabulary) to make the intent clear that such properties are "local imports" made to facilitate usage. I think so because defining a subproperty which is just an alias may otherwise seem a bit gratuitous. (Worse though is defining "yet another" property which *seems* to have the semantics of an already established one (DC terms case in point) without any linkage saying so. When defining vocabularies, I generally believe research of existing ones should be done to avoid reinvention. The "proxy pattern" could sell this argument better than just "use OWL".) > Relying on RDFS or OWL inference is something that is typically only done in reasoning, not as part and parcel of basic processing. Including a mechanism such as you describe could be a bridge to encourage better use existing vocabularies, without giving up the advantage of a single namespace. Precisely! This calls for coordination with the larger RDF community though. My suggested use of proxy definitions require acceptance and uptake to be beneficial. A vocabulary for that should be a simple, generalized one which defines this pattern clearly, and defines where it fits between "just triples" and RDFS entailment/full inference (for consumers/re-users to use judiciously). > As you say, other users may be satisfied with a syntactic representation; we've found this with JSON-LD as well, where many (most?) uses may never get to RDF, but there's advantage in having well understood representation and processing rules. Indeed. Users/publishers might not see the value in mixing (even well known) vocabularies, but vocabulary authors could (and perhaps should) provide for that at the vocabulary level. (Of course, sometimes you want to express richer data using multiple vocabularies anyway. But that's what @prefix and CURIEs are for.) Now, there is surely a question here as to what the RDF Web Applications WG should focus on, and what is up to the general RDF community (the RDFS/OWL community really). The suggested proxy mechanism is for the domain of vocabulary authors, and for consumers who rely on interlinked RDF semantics. Only if this is an embraced pattern will it be truly feasible to recommend it for RDFa. But I believe the RDFa context is a good starting point, being a concrete place where (mixed) vocabulary usage takes place. (There are also things to consider on a general level for a "map vocabulary" of course, such as subPropertyOf versus equivalentProperty (or making a subproperty of subPropertyOf..), the value of coercion and handling inverseOf in my extended example [1], etc. And there are theoretical grounds to cover; "OWL:isms" to be aware of. (On that note, I've also used "protege:abstract" (see e.g. [2] and [3]) on occasion, and can see value in having such a mechanism. But that would likely not be of any specific value for RDFa.)) Best regards, Niklas [1]: https://github.com/niklasl/rdf-sparql-lab/tree/master/curation [2]: http://protege.stanford.edu/doc/tutorial/get_started/make_class_abstract.html [3]: https://mailman.stanford.edu/pipermail/protege-owl/2011-January/015866.html > [1] http://www.w3.org/TR/mediaont-10/
Received on Thursday, 21 July 2011 15:59:28 UTC