Re: RDFa profile microsyntax, proxy vocabularies, GRDDL

On the call today, we discussed option 2 a bit more. My assertion was that it is similar to some RDFS entailment rules [1]. The main difference is that AFIK, RDFS entailment rules must be repeated an indeterminate number of times, whereas  the mapping rules need only be run a single time. Also, there aren't really RDFS entailment rules that are run generally for URIs that aren't properties or classes.

As a summary, we might consider the following case:

<span vocab="http://example.com/vocab#" property="foo">Bar</span>

This would then generate the following triple:

@prefix : <http://example.com/vocab#> .

<> :foo "Bar" .

If the vocab document had something such as the following:

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix : <http://example.com/vocab#> .

v:foo rdfs:subPropertyOf dct:title .

We could run the following RDFS entailment rules from [1]:

rdfs7: uuu rdf:subPropertyOf bbb .

to create the following triple:

<> dct:title "Bar" .

(owl:equivalentProperty is probably more accurate, but let's stick with RDFS for now).

Now, with RDFS entailment, we may need to repeat these steps until no more triples are added to the graph, as we may have a chain of subPropertyOf definitions, and other rules may come into play.

Because the term resource does not necessarily need represent either a class or a property, we don't have equivalent inference rules to use. However, Niklas originally described map:ProxyClass and map:ProxyProperty, which would presume that they represent rdf:Class and rdf:Property URIs.

In any case, I think we have a basis for describing the behavior of a hypothetical "Map" entailment regime, that could be expressed in the form of a SPARQL CONSTRUCT expression that would perform the necessary first-order mappings. It might be expressed something like the following:

PREFIX map: <http://example.org/map#>
PREFIX owl: <http://www.w3.org/2002/07/owl#>

CONSTRUCT { ?s1 ?p ?o . ?s ?p1 ?o . ?s ?p ?o1 }
FROM NAMED <http://example.com/vocab#>
WHERE {
  GRAPH <http://example.com/vocab#> { ?s a map:Proxy; owl:sameAs ?s1 }
  { ?s ?p ?o }
}
UNION {
  GRAPH <http://example.com/vocab#> { ?p a map:Proxy; owl:equivalentProperty ?p1 }
  { ?s ?p ?o }
}
UNION {
  GRAPH <http://example.com/vocab#> { ?o a map:Proxy; owl:sameAs ?o1 }
  { ?s ?p ?o }
}

(The SPARQL can certainly be improved upon, but it's probably not necessarily the way a processor would implement it anyway.

Adding a section where a processor resolves the vocabulary and runs rules such as these would result in a graph that as new triples created based on these rules; this would allow use of both :foo and dc:title, for example to get the associated resources. There could potentially be another step which results in removing the vocabulary terms, which should then have the same number of statements as the original document before the mappings were applied, but with the translations put in place.

Gregg

[1] http://www.w3.org/TR/rdf-mt/#RDFSRules

On Jul 21, 2011, at 8:58 AM, Niklas Lindström wrote:

Hi Gregg!

2011/7/20 Gregg Kellogg <gregg@kellogg-assoc.com<mailto: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<http://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/