W3C home > Mailing lists > Public > public-dxwg-wg@w3.org > December 2017

Concepts Re: Start of profiles analysis page - 2nd reply

From: Karen Coyle <kcoyle@kcoyle.net>
Date: Mon, 11 Dec 2017 04:49:15 -0800
To: public-dxwg-wg@w3.org
Message-ID: <0bba534e-1612-0d54-7b0f-a5063834c166@kcoyle.net>

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).

I've probably spent way too much time pondering and arguing the concept
of "concept", which is why the use of "concept" or "conceptual" always
worries me. Makx referred to the FRBR "work", which I spent whole
chapters of a book trying to understand and define [1]. If by concept we
mean an unexpressed idea, then there's obviously nothing that can be
serialized, as is desired. Nor can an idea be queried through an API.
The base expression of a profile must take some tangible form, or we
have nothing to operate over.

To me this implies a particular question: are we concerned about the
tangible form that a profile takes? Or are we only concerned with the
ability to respond to an API, and the form that response takes? Because
these imply different "solutions" and we might want to discuss them
separately, and develop terminology so that we can discuss them

As an example, there may be no "application profile" as such for the
library standard MARC21, but one could conceivably request a file of
records using that standard. The API functionality seems able to work
with designations that are not application profiles (as we seem to be
defining that).

Once again the deliverable of a guidance for APs and the deliverable of
API by "AP" seem to me to be more separable than stated in the charge.

[1] http://kcoyle.net/beforeAndAfter

> 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.
>> 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 Monday, 11 December 2017 12:49:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:41:58 UTC