- From: Karen Coyle <kcoyle@kcoyle.net>
- Date: Wed, 6 Dec 2017 07:56:28 -0800
- To: Ruben Verborgh <Ruben.Verborgh@UGent.be>
- Cc: "public-dxwg-wg@w3.org" <public-dxwg-wg@w3.org>, "mail@makxdekkers.com" <mail@makxdekkers.com>
On 12/6/17 2:59 AM, Ruben Verborgh wrote: > Hi Karen, > >> 1. How can we (or "can we") define an AP that works for both RDF/OWL and >> non-RDF/OWL metadata? Or do we need to provide more than on option in >> our guidance? > > By distinguishing between the profile as a concept > and a representation of a profile as a document > (similar to what Makx wrote). > > For example, we can have an AP for a certain government, > and specification documents can exist for the RDF case > and for a non-RDF case. > > A concrete way to realize this is with content negotiation > on the IRI of the profile. For example > http://example.org/profiles/xyz/ > could result in HTML, RDF, XML Schema, or JSON schema > depending on the Accept headers of the client. Not all access to APs will be through content negotiation, AFAIK, so we have to consider other access avenues, such as a document at is located on a web site, profiles in wikis, etc. If there is a "concept" AP it needs to be something that can be represented, thus is not entirely abstract. That seems to be the thing that we are tasked with describing - the "concept" xyz that can be rendered in various formats. I'm not sure that a solution that requires rendering a format through content negotiation will satisfy all of the interested organizations. That's another thing that we should clarify. I was thinking of content negotiation and profile guidance between more separate than what you describe here. I've been looking at the CSVW standard [1], which allows folks to express their data as a table or a series of tables, and these can then be converted (not necessarily on the fly) to other formats. This looks promising because most of the profiles that I've seen take a tabular form, so this seems to be a structure that people are comfortable with. That's an important point, I think: profiles need to be easy to create by people who don't necessarily write code. I'm not sure that's a requirement we've embraced, so another one that we should discuss. kc [1] https://www.w3.org/2013/csvw/wiki/Main_Page > >> 1a. Do we require that terms are identified with an IRI? Non-RDF/OWL may >> not have IRIs. > > Only when the content type of the response is RDF. > >> 2. Could an RDF/OWL-based AP define terms within the AP? > > It _could_ do that, > but it seems more appropriate to define this elsewhere. > > Let me make that more concrete. > Suppose that the following is a profile: > http://example.org/profiles/xyz/ > then it is possible to have terms such as > http://example.org/profiles/xyz/#foo > http://example.org/profiles/xyz/#bar > but probably more appropriate to have > http://example.org/ontologies/abc/#foo > http://example.org/ontologies/abc/#bar > such that the term definition is not tied to the profile > and can more flexibly be used in other profiles. > > Best, > > Ruben > -- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net m: 1-510-435-8234 (Signal) skype: kcoylenet/+1-510-984-3600
Received on Wednesday, 6 December 2017 15:56:57 UTC