Re: Start of profiles analysis page - 2nd reply

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


>> 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:
> then it is possible to have terms such as
> but probably more appropriate to have
> such that the term definition is not tied to the profile
> and can more flexibly be used in other profiles.
> Best,
> Ruben

Karen Coyle
m: 1-510-435-8234 (Signal)
skype: kcoylenet/+1-510-984-3600

Received on Wednesday, 6 December 2017 15:56:57 UTC