Re: [dxwg] A profile must be packaged as a self-contained artefact

@agreiner  commented 5 days ago

So, my concern with this is that I think profiles should be self-contained. One should not have to find parent profiles in order to make sense of a profile already in hand. I have no problem with a profile indicating its provenance, but any programmatic use of a profile is made unnecessarily complex if it requires finding parent profiles and parsing them separately. As a web app developer, I don't want to have to build a semantic engine in order to build an app that uses a profile to determine what inputs it can use.

 @dr-shorthair commented 3 days ago
@agreiner doesn't that miss the point? We re-use existing technologies in order that we don't have to reinvent/redescribe them. And it can never be fully self-contained unless you also include the definitions and axiomatizations &| shapes for DC, OWL, RDFS, RDF, URIs, etc etc, which is obviously not what you mean at all! I think we are talking about functions equivalent to include/import and frankly if and pre-processing a profile by getting the dependencies first seems totally reasonable to me.

 @rob-metalinkage  commented 2 days ago
This is an important discussion about implementation - while the implementation and the model are different, we should see if the model should provide better support for certain implementation patterns.

Certainly profiles cannot be realistically created "flat" - and must be constructed from a hierarchy - and here I will cite several reasons, (others may exist)

the burden on clients to work out what is the same and what is different from complicated flat (self-contained) profiles is far greater than that to combine profiles
services and catalogs can do all the work of creating flat views of profiles
descriptive object languages all implement hierarchy
Its far easier to write an extension with a few extra clauses than package up a and document a self-contained profile
We probably lose semantic information about intent (even if it is possible to compare flat profiles for equivalence)
comparison of flat profiles will be dependent on being able to parse the actual profile constraints lagnguage used. This is simply not feasible for text forms in current practice, and would require delving into the details of those languages where we think it can be done.
specific constraints might need to specify where they come from - possibly creating a burden on us to choose a canonical profile constraints or a set of conformance criteria about the expressivity of such languages
So, given that clients will want to access a flat view - is there anything we can do in the model to help:

for example, SKOS has skos:broader and skos:broaderTransitive

A profileOf B
B profileOf C

should entail A profileOfC

A profileOf B,C

is legal - but loses the hierarchy. If we make profileOf point to the immediate parent only, then its hard to refactor - to create an extra category of profiles of B with commonalities.

These are quite well known patterns - it would be great to agree on the most useful form for a "self-contained view" of a profile and how this may be defined (its probably a profile of the profile ontology :-) )

GitHub Notification of comment by dr-shorthair
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 8 May 2018 10:29:50 UTC