W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > July 2011

Re: RDFa profile microsyntax, proxy vocabularies, GRDDL

From: Niklas Lindström <lindstream@gmail.com>
Date: Thu, 21 Jul 2011 17:58:37 +0200
Message-ID: <CADjV5jcUds77qfmnPFJQF9qiCnNkK_v5NP2SscOdyfUzKMXP6g@mail.gmail.com>
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

(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

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

[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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:52 UTC