Martin,
my real question is whether, in your experience, the generic RDFa @vocab processing should also include the basic owl:equivalent*** term processing (essentially saying that the processing level should be a mini version of OWL 2 RL). This may be an important feedback to the RDFa WG.
Ivan
On Oct 20, 2011, at 11:40 , Martin Hepp wrote:
> Hi Ivan:
>
> We introduced this pattern when we wanted to rename three GoodRelations classes that were already widely used. At that time, we investigated various approaches but found that only this one
>
> - preserves backward compatibility, in particular in terms of querying old data using new element URIs,
> - works in all syntactical representations for RDF and
> - remains within OWL DL for usages in controlled DL settings.
>
> I think this is an important feature as far as the older GR elements are concerned, because there is a lot of data out there relying on the old URIs.
>
> As for the schema.org alignment, I would not want to use a second pattern, because that would add a lot of complexity. Also, any solution we use should be as syntax-neutral as possible, allowing to consume GoodRelations data in any EAV environment.
>
> Martin
>
> On Oct 20, 2011, at 11:31 AM, Ivan Herman wrote:
>
>> Thanks Martin,
>>
>> this does raise a side-issue for the RDFa WG, though. At the moment, we have defined an RDFa @vocab feature whereby an RDFa processor can follow its nose to pick up a vocabulary definition with the URI in the @vocab, and process some of the simple RDFS statements there to help vocabulary alignments. At present, the document defines a very minimal vocabulary to be processed, essentially subclass and subproperty. We did not include the more powerful OWL notions, ie, equivalentXXX. Do you think this is very necessary? If so, this may have to be raised at the RDFa WG.
>>
>> Ivan
>>
>>
>>
>> On Oct 20, 2011, at 10:36 , Martin Hepp wrote:
>>
>>> Hi Ivan, all:
>>> On Oct 20, 2011, at 9:23 AM, Ivan Herman wrote:
>>>
>>>> (Martin, an explicit question to you below)
>>>>
>>>>> My preference would be option 3, where there is a single way to parse, without reference to vocabulary specifics. This would be in direct contrast with the HTML spec, but more in lines of the needs of RDF tool chains.
>>>>>
>>>>
>>>> Yes, I see. I would like to see a use case where this does not work (and, from the top of my head, I do not see any).
>>>>
>>>> Except that (hence my explicit cc to Martin): let us suppose that, eventually, the GR terms will be incorporated into schema.org. What this means is that all GR terms will be in the schema.org/ namespace, but that also means that a microdata->RDF mapping would produce the GR terms as
>>>>
>>>> http://schema.org/Blah
>>>>
>>>> which is different than the current terms. Martin, what are your plans with the old URI-s in that situation?
>>>
>>> there is not yet a decision made, but one likely approach is to add some, most, or all GoodRelations properties to matching schema.org classes. However, this does not mean that the main namespace for GoodRelations changes. It just means that you can use the respective GoodRelations elements also within the schema.org namespace and with local names inside the respective schema.org itemtype.
>>>
>>> My current plan is to include proper alignment axioms to at least the OWL version of GoodRelations so that any client that
>>>
>>> - consumes the respective data in an RDF environment,
>>> - supports at least basic reasoning for rdfs:subClassOf, rdfs:subpropertyOf, owl:equivalentProperty, owl:equivalentClass, and owl:sameAs for simple (i.e. atomic) class definitions (no fancy DL reasoning needed)
>>>
>>> will work with the same SPARQL queries, no matter whether the annotations are in RDFa or Microdata, from the GoodRelations namespace or from schema.org shortcuts.
>>>
>>> So basically you will have three cases:
>>>
>>> a) GoodRelations markup in RDFa
>>> b) GoodRelations markup in Microdata
>>> c) GoodRelations properties, classes, or individuals using the schema.org aliases in Microdata syntax.
>>>
>>> All three should eventually match to the same queries.
>>>
>>> So for example,
>>>
>>> http://purl.org/goodrelations/v1#hasDUNS
>>>
>>> may also become a property for
>>>
>>> http://schema.org/Organization
>>>
>>> using the local name
>>>
>>> hasDUNS
>>>
>>> Using the standard algorithms, you will likely get the URI
>>>
>>> http://schema.org/hasDUNS
>>>
>>> for this.
>>>
>>> But since the GoodRelations OWL specification will state
>>>
>>> @prefix gr: <http://purl.org/goodrelations/v1#>.
>>> @prefix schema: <http://schema.org/> .
>>>
>>> schema:hasDUNS a owl:DatatypeProperty .
>>> # we will NOT duplicate the other aspects of the property definition here; this is just for the sake of OWL DL compatibility.
>>>
>>> schema:hasDUNS owl:equivalentProperty gr:hasDUNS. ,
>>>
>>> a query using schema:hasDUNS will return the same results as a query using gr:hasDUNS.
>>>
>>> Note 1: For us, it is most important that you can consume (!) the data using one single vocabulary, i.e. the official GoodRelations identifiers. In many cases, the mapping will work bidirectionally, but that is not a requirement.
>>> Note 2: The schema.org OWL file may or may not include similar alignment axioms to GoodRelations.
>>> Note 3: The domain of gr:hasDUNS will also include the matching schema.org classes via owl:unionOf, btw.
>>>
>>> Okay?
>>>
>>> Martin
>>>
>>
>>
>> ----
>> Ivan Herman, W3C Semantic Web Activity Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153
>> PGP Key: http://www.ivan-herman.net/pgpkey.html
>> FOAF: http://www.ivan-herman.net/foaf.rdf
>>
>>
>>
>>
>>
>
----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF: http://www.ivan-herman.net/foaf.rdf