Re: RDFa profile microsyntax, proxy vocabularies, GRDDL

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.

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.

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.

Gregg

[1] http://www.w3.org/TR/mediaont-10/

On Jul 19, 2011, at 5:41 PM, Niklas Lindström wrote:

> Hello all!
> 
> I've considered the case of profiles for a while, and I've conceived
> some alternatives. This became rather lengthy, but I hope you'll find
> it informational.
> 
> My perspective here is regarding our goal to make RDFa 1.1 really easy
> for people (with various knowledge) to read and write, while
> supporting mixed use of vocabularies and the fundamental RDF model.
> 
> We are exploring means of reducing the needs for prefixes and CURIEs
> for simple cases. Currently, the @vocab attribute and the use of
> profiles handles this. But profiles come at a potential cost which is
> under debate.
> 
> ## Complexity of profiles ##
> 
> It is arguably so that profiles *are* complex, using "out of band"
> indirection to support the URI-based solution for mixing vocabularies.
> 
> The profile solution in its current form may also come across as
> convoluted. It provides means of *syntactic* shortcuts, leaving
> certain forms of expressions in RDFa attributes *dependent* on them. I
> find it a bit awkward to parse RDFa in profiles in order to enable the
> parsing of *some* of the RDFa in the main document. That also puts a
> cognitive burden on anyone who wants to understand what's really going
> on.
> 
> I get a general sense that profiles may be halfway towards somewhere.
> I see some different paths ahead:
> 
> 1. A common microsyntax supporting prefixes, default vocab and terms;
> used inline in @prefix or linked to with @profile.
> 2. Remove profiles, promote "proxy vocabularies" with @vocab for the
> simplest scenarios.
> 3. Turn profiles into a full GRDDL mechanism.
> 
> 
> ## 1. A profile microsyntax ##
> 
> One concern I have with profiles now is that they are directives given
> as RDF for how to syntactically parse references. (I believe you've
> debated this a lot already, but I can't help finding it awkward.) A
> solution to this can be quite simple:
> 
> * Extend @prefix to support declaration of default vocab and terms.
> * Define the profile syntax to be, verbatim, the syntax used in @prefix.
> 
> These extensions to @prefix can be really simple too. For instance, how about:
> 
>    : http://www.w3.org/1999/xhtml/vocab#
> 
> to declare the default vocab; and:
> 
>    :describedby http://www.w3.org/2007/05/powder-s#describedby
> 
> to declare a term. (Or perhaps another token than ":" for these, such
> as "@", to make it more distinguishable.)
> 
> If external @profile references are to be supported (barring issues of
> callbacks and broken links), I'd suggest that these (small) documents
> are to be following a same origin policy (i.e. placed locally on the
> server along with the documents using it).
> 
> (I just noticed that this looks a lot like Mark Birbeck's previous
> suggestions in e.g. [1].)
> 
> 
> ## 2. Mapping on the semantic level ##
> 
> This alternative is quite different from profiles. It uses the power
> of linked data in its own right.
> 
> As I considered the use of profiles, I got the impression of being
> halfway towards custom vocabularies. So why not define *proxy
> vocabularies* which maps (i.e. *links*) to other (more known) terms?
> We already have what we need for that in RDF Schema, namely
> subPropertyOf and subClassOf. Stéphane also mentioned this, suggesting
> that we should use vocabularies with term mappings. (I'm not sure if
> this is really what you meant Stéphane, but it is what I will go for.)
> 
> In some of the scenarios we're coming across now in RDFa, it seems
> there may be an advantage to "importing" recommended terms into your
> own vocabulary. By doing so, users don't need to mix vocabularies.
> (Although mixing is arguably a good thing, it takes some experience to
> see that).
> 
> (Neither Facebook OpenGraph nor schema.org even *link* their terms to
> precursors (FOAF, GoodRelations etc.), much to the dismay of RDF users
> who wish to integrate such data with already existing terms.)
> 
> A way which takes this into consideration, is to define a mapping
> vocabulary which defines a set of classes and properties intended to
> work as "aliases" or "proxies" (e.g ProxyClass/ProxyProperty). That
> is, they are sub-concepts of some property or class, but define no
> additional semantics, apart from the intent of using them within the
> domain context of a specific vocabulary.
> 
> Such a vocabulary could be *just* a "proxy vocabulary", or it could be
> a regular one which chooses to "import" certain terms important to
> them.
> 
> Such vocabularies are to be used in a way reminiscent of RDFa
> profiles, but *not* within the parsing context. That is, from an RDFa
> point of view, the data is ready and in RDF form. The vocabulary will
> be used by consumers of RDF who wish to process and integrate it with
> other data, in any way deemed usable.
> 
> This will be a very cheap solution for publishing in many cases. It
> *will* require RDF-savvy users to interpret the data (the used
> properties and classes), but it will do so using established RDF
> concepts. That is, on a *semantic* level, not a syntactic! (Granted,
> we may invent the mapping/proxy concept, but by using
> subPropertyOf/subClassOf, any system supporting direct RDFS inference
> will work as expected. And this mapping vocabulary may turn out to be
> generally beneficial.)
> 
> ### Mapping vocabulary example ###
> 
> I've put together a small example of how this could look at:
> <https://gist.github.com/1092350>
> 
> It includes:
> 
> * some example site data,
> * a (site specific) proxy vocabulary (using the suggested "map" vocabulary),
> * an implementation using SPARQL 1.1 CONSTRUCT,
> * new, mapped data with proxy terms resolved to terms from other vocabularies.
> 
> I've also done an extended (functional) experiment of this at
> <https://github.com/niklasl/rdf-sparql-lab/tree/master/curation>. It
> goes even further by also:
> 
> * "fixing" values by coercing them to expected datatypes or IRIs,
> * handling "proxied" inverses of properties (?s ?p ?o => ?o ?invP ?s ).
> 
> It is important to understand that this example illustrates *use* of
> the data. With this alternative, RDFa would just have to support
> @vocab. Nothing more. The rest is in the semantics of the links.
> 
> (And I'm not suggesting to remove @prefix at all. That'd be the
> mechanism of choice for anyone mixing vocabularies which don't use any
> mapping/proxy semantics to include other terms.)
> 
> ### Remaining: the "default profile" ###
> 
> One thing still remains though. We still have the predefined set of
> prefix declarations and term mappings available by default. It could
> be kept as a hard-wired, built-in set tied to the host language.
> 
> Prefixes and default vocab can reasonably have defaults, but terms
> would have no customisable equivalent in the RDFa syntax. And there is
> an issue, which Shane points out, where a predefined term overrides a
> term intended to be resolved against a given @vocab.
> 
> One way to solve that could be to remove the notion of predefined
> terms, and state that the default vocab is
> <http://www.w3.org/1999/xhtml/vocab#>  *unless overridden*. If one
> uses @vocab, one have to use e.g. "xhv:license" explicitly. Or the
> other way around, if one wants e.g. rel="license" to resolve against a
> custom @vocab, one'd have to use rel=":license"...
> 
> 
> ## 3. Profiles revisited as GRDDL ##
> 
> There may of course be more complex scenarios where a multitude of
> vocabularies intermix directly, and a declarative indirection (even
> "macros") may be warranted.
> 
> There is already a W3C standard to explore though: GRDDL [2]. It can
> be used in any complex scenario. I'd suggest that those who actually
> need this complexity explore whether GRDDL as it stands will suffice.
> 
> If not, I can imagine a refined declarative mechanism for GRDDL, based
> on the current profile mechanism. It could use either @class and @id,
> the "app specific" data-attributes of HTML5, or.. microdata (depending
> on how the current schism is resolved). Think "microdata + profiles =
> GRDDL 2.0". I'm not saying I'd prefer this, but it is an option (one I
> actually gravitated towards prior to the notion of "proxy
> vocabularies").
> 
> Such a mechanism could do more than simply map terms/tokens to URIs.
> One can imagine coercing values, converting strings and id tokens to
> URIs, creating RDF Lists from elements, etc. That would provide
> app-specific, declaratively indirected means of expressing RDF for use
> by experts with demanding requirements.
> 
> But that is reasonably beyond what the RDF Web Applications Group
> should do now. Such a path would become work on some new GRDDL
> mechanism (say hGRDDL, as Ben Adida thought of some years ago [3]).
> 
> 
> ## Summary ##
> 
> To repeat, my suggested alternatives are:
> 
> 1. An extended @prefix microsyntax with support for prefixes, default
> vocab and terms. Support for linking to such declarations using
> @profile.
> 2. Removal of profiles in favour of "proxy vocabularies" for really
> simple "one vocab fits all" scenarios. Use nested @vocab or @prefix as
> they stand now for regular vocabulary mixing.
> 3. Turn profiles into a GRDDL mechanism, ideally not overloading the
> RDFa attributes but instead working on a declarative level upon either
> @class and @id, data-attributes or microdata attributes.
> 
> Currently I lean towards proxy vocabularies (alternative 2). But I'd
> love to discuss this further.
> 
> Best regards,
> Niklas Lindström
> Valtech AB
> 
> [1]: http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Oct/0238.html
> [2]: http://www.w3.org/2003/g/data-view
> [3]: http://lists.w3.org/Archives/Public/public-rdf-in-xhtml-tf/2006Apr/0069.html
> 
> --
> <http://neverspace.net/>
> <http://valtech.se/>
>

Received on Wednesday, 20 July 2011 01:57:37 UTC