Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

property profileOfTransitive #486

Open
riccardoAlbertoni opened this issue Oct 23, 2018 · 70 comments

Comments

Projects
None yet
10 participants
@riccardoAlbertoni
Copy link
Collaborator

commented Oct 23, 2018

I guess the intention for profileOfTransitive was to replicate the modelling pattern adopted for the broaderTransitive and broader properties in SKOS.
In that case, I have two issues:

  • I would consider renaming this property in "transitiveProfileOf". Of course, I leave the last word to native speakers but while "broaderTransitive" works well to me, "profileOfTransitive" is a little confusing, probably due to the 'Of" before "Transitive" which might be interpret as "profile of transitive" instead of "profileOf transitive".

  • In order to replicate the skos:broader /skos:broaderTransitive, the following statement might be added

prof:profileOfTransitive rdf:type owl:ObjectProperty , owl:TransitiveProperty .
prof:profileOf rdfs:subPropertyOf prof:profileOfTransitive .
 
@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 23, 2018

@riccardoAlbertoni I will give you a thumbs up from a native speaker point of view regarding profileOfTransitive, but I would also question whether "transitive" expresses the intended meaning here. Although the usage here is similar to SKOS's broaderTransitive, I feel like the relationships between profiles is more complex than the "broader/narrower" type as used in SKOS. I am thinking of the case where:

vocabularyA exists
vocabularyB exists
profileC is a profile of A and B although it uses only portions of A and B
profileD is a profile of C using some portions of profileC but adding terms from another vocabulary

Under what conditions could you say that profileD is a profile of(transitive) profileC? Do they have to use all of the same terms and constraints? I feel like this question gets very complex very quickly. At the very least, there would need to be rules that govern transitivity.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

Happy to take on board the suggestion and see what the consensus is.

its important to be clear of the semantics here :-)

def of transitive : "(of a relation) such that, if it applies between successive members of a sequence, it must also apply between any two members taken in order. For instance, if A is larger than B, and B is larger than C, then A is larger than C."

or in the OWL spec; "When one defines a property P to be a transitive property, this means that if a pair (x,y) is an instance of P, and the pair (y,z) is also instance of P, then we can infer the the pair (x,z) is also an instance of P."

a object conforming to profile A is also conformant to all profiles P where A transitiveProfileOf P

so for the case:
"profileC is a profile of A and B although it uses only portions of A and B "

profileC is still bound by any cardinality constraints in either A or B

NB a vocabulary where terms are defined and no cardinality is defined (everything is optional) means that any object may "conform" to it if the use of those properties are consistent. We may need to think about the case where no properties are used at all

is the graph

"A1 a owl:Thing . "

conformant to a profile of dublin core that introduces no cardinality constraints?

would we need to safeguard reasoners against lots of trivial conformance statements?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

also we could consider

profileTransitiveOf

as perhaps closest to the skos without the ambiguity ?

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

@rob-metalinkage If "profileOf" and transitive here means "bound by cardinality constraints" then that needs to be included somewhere in the document. There is nothing inherent in "profile of" conceptually that would imply such a rule. The OWL definition of transitive establishes a relationship but does not define specific rules based on the entailments from that relationship, which presumably would depend on the nature of the things being related. Even if we could say that "bound by cardinality constraints" is a logical result of the "profileOf" relationship, I think that needs to be made clear for readers. I'm also wondering what other entailments might be assumed from the profileOf relationship - including things like labels, definitions, etc.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

agree we should make sure its well explained in examples.

profile transitivity is a simple declarative statement that is transitive.

The existence of resources that are qualified by the profile that introduced the resource could be expressed as an entailment of the resource property.

these are the only two I think.

Do you think any other entailments are appropriate and why?

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

Actually, I prefer not to assume entailments, because in general I think they are not used/implemented. I also think that they are often not understood. So if this vocabulary includes some functionality based on entailments that needs to be expressed very clearly.

I have not yet encountered a profile that has functionalized entailments from its base vocabularies. However, it may be that people haven't thought about it, so a good explanation (even as a note accompanying the proposed vocabulary) would be useful.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Oct 24, 2018

@kcoyle we do see profiles using entailment from base vocabs every time a Profile extends a structured codelists, e.g. a vocab. By placing new terms in a hierarchy - maybe addin more, finer grained leaf nodes, the profile is leveraging the base space vocab’s hierarchy for classification.

Also, any specialised ontology of another is a profile carrying forward entailments from the base spec.

Having said that, I agree with you this is rare for people in pure DCAP-like profile land and also agree it’s probably because people haven’t easily had the mechanics at hand to do this and that they may now be able to do it more - a functional win.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 25, 2018

@nicholascar "Also, any specialised ontology of another is a profile carrying forward entailments from the base spec."

Here I think we need to carefully define what we mean by "entailment". The meaning I was using was the actual axiomatic usage in RDF, which is effected in code. This kind of entailment adds triples to the graph. In a non-RDF environment, it would add some code to existing code, as in your example of placing new terms in a hierarchy.

I do not use "entailment" to mean intellectual or semantic "carry-over", such as re-using dct:title without further definition because your community knows very well what it means.

I agree with @agreiner in her concerns about "cascading" profiles, and I think that the profiles that we see in the wild support her view that a stand-alone profile is what most people are comfortable with. For that reason, I think that any entailments inherent in the ontology need to be clearly spelled out - in part so that people can understand if they need them.

This is my worry about "profileOf" - one could say that DCAT-AP is a profileOf DCAT, yet DCAT-AP does not allow any code entailments from DCAT, AFAIK. If "profileOf" means that there are entailments, then it would not be correct for DCAT-AP to use that. Yet it seems quite natural to consider DCAT-AP a profile of DCAT. So the definition and implications of the use of "profileOf" are very important and need to be spelled out. Can a stand-alone profile be a profileOf something? What is the algorithm for entailment of profileOf? In ODRL it means (as I understand it) to carry forward ALL properties of the base profile. I don't think that's what we mean since we say that profiles can select properties from a variety of base vocabularies. So what exactly is the effect of profileOf on the content of the profile?

@aisaac

This comment has been minimized.

Copy link
Contributor

commented Oct 27, 2018

I'm sorry to be a pain, but this issue has become quite unreadable. I guess the notion of the 'transitive profile of' property is just to be able to navigate over chains of 'profile of' statements, whatever the single 'profile of' steps may mean in terms of entailment, partial or full conformance, etc. If it's the case, then discussion on what the single 'profile of' steps mean, relevant at it is, should be transfered to another ticket.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 28, 2018

I agree. I'll start a new issue and copy some of this over.

@aisaac

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

Maybe the discussion on #507 will result in a change of name from 'profile of' to something else. But in any case, +1 for @riccardoAlbertoni 's original suggestions on the patterns, both the naming pattern and the axioms to be added.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 29, 2018

I'm happy to make these changes before FPWD. do we have consensus?

profileOfTransitive => transitiveProfileOf

prof:transitiveProfileOf rdf:type owl:ObjectProperty , owl:TransitiveProperty .
prof:transitiveProfileOf rdfs:comment "This is consistent with the SKOS model of broader and broaderTransitive" .
prof:profileOf rdfs:subPropertyOf prof:transitiveProfileOf .

+1 from me, @aisaac and @riccardoAlbertoni (presumed) so far then

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

+1 although the rdfs:comment might work better as a skos:usageNote reading: "This is consistent with the SKOS model of broader and broaderTransitive and should be used accordingly."

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

Karen has asked some important questions about the transitivity concept that I've been hoping to see some answers to myself. I am having a hard time thinking of real-world use cases for this, and I think that needs to be balanced against the complexity. Does it even make sense to make claims about transitivity when defining only one profile? What would they mean? What would such statements enable?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 30, 2018

@agreiner please refer to the multiple Use Cases that clearly identify that profiles are transitively hierarchical (they inherit all constraints of base profiles). So we provide a way to "flatten" these things out so that clients do not need to walk the hierarchy if a server is willing to do the work to flatten them out.

or look at the SKOS spec, and the way skos:broaderTransitive is defined - and may be entailed from skos:broader (or provided entailed in the resource at the server's discretion)

fair enough to think about best practices for entailment (and avoiding run-time entailment) but the rationale is clear enough, and the requirements have been discussed multiple times and agreed, so now we need to focus on a solution, not re-opening the debate.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

I think we should look closely at those "multiple use cases" to try to understand what definition of "hierarchy" they require. Which ones are you referring to?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

Europeana, DCAT-AP family, Nicks Aust gov example. We dont actually have any examples without a hierarchy.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

Property profileOfTransitive renamed to transitiveProfileOf in commit be299e4

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

Ok, both Europeana and DCAT-AP have made clear that their profiles are "flat" - that is, every profile is a stand-alone. There is logical semantic "inheritance" but no algorithmic inheritance is required or desired. That is one case for profiles, and it seems to be by far the predominant one. There is no "transitivitiy" to act on in these profiles. In fact, it would probably be inaccurate to say that every instance of DCAT-AP-x is a valid DCAT-AP, as some changes may have been made. For sure, other elements have been added that would not be valid in DCAT-AP. Therefore, they are not hierarchical, in the broader, narrower sense, and they are not transitive, as the changes would make them invalid.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

" There is logical semantic "inheritance" " - hence the abstract model has inheritance and this is supported by the profiles ontology

" that is, every profile is a stand-alone." - hence the profiles ontology supports implementations that are "flat"

The issue of non-conformance is more complicated - no formalism would ever allow this - so if this is the case they are not profiles of each other - only confusingly named. What we need then is additional evidence in the Use Case and additiona requirements - and we could respond with additional support in the profiles ontology ( notAProfileOF X) to indicate this semantic disjointedness.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Oct 31, 2018

it does sound that it would be a requirement to have a specialisation of role to distinguish between artefacts that are flat and those that are normative constraints specific to profile

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

@rob-metalinkage Can you state what your definition of profile is, and what formalisms it requires? Because the definition we have now does not mention any requirement of inheritance or conformance that would be testable. As a shortcut, here's the definition:

_A named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function. _

Also, based on this definition, is DCAT-AP a profile? Does it meet your definition of profile?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

I think this is worth making more explicit - that a profile itself is a specification. Whilst its pretty obvious under any rational interpretation of specification that a set of constraints is a specification, I think you have raised a valid concern about its ease of interpretation, and it won't hurt to reinforce this:

_A profile is a specification consisting of a named set of constraints on one or more identified base specifications, including the identification of any implementing subclasses of datatypes, semantic interpretations, vocabularies, options and parameters of those base specifications necessary to accomplish a particular function. _

It does not specify testability as this is a platform and community specific concern - there is a default assumption of testability of "by inspection" that doesnt need to be in the definition.

DCAT-AP is a profile of DCAT if and only if data conformant to DCAT-AP is conformant to DCAT (which I understand is true)

If we have a requirement to express "partial conformance" we need an explicit use case we can derive it from.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

@rob-metalinkage I don't know what adding the word "specification" does here. Can you say what difference it makes? Basically, what is the difference between "a profile is a named set of" vs "a profile is a specification consisting of a named set of"? Are you importing certain qualities to the word "specification" that are not already in the definition?

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

Perhaps the idea is that a specification might include more than simply the constraints. The term constraints is a little tricky. Following the modular specification logic, its useful to think of a specification in terms of requirements and conformance classes. Most existing specs only explicitly define one conformance class--meets all requirements, and this typically is about some specific implementation/serialization/syntax. Usually there are some requirements stated using the standard RFC2119 language, but often there is an underlying implicit conceptual or logical model that establishes unstated requirements as well. Perhaps one of the problems with thinking about profiles is that they might conform to implicit requirements (conceptual or logical), but not the explicit one.

As far as transitivity, can we define different relations (names are for discussion purposes here). A and B are specifications; since multiple conformance classes are rarely defined, these are based on requirements. For example:

  1. isType1ProfileOf -- if A isType1ProfileOf B, then instances of A meet ALL requirements in B, and requirements in A are all restrictions of requirements in B.
  2. isType2ProfileOf -- if A isType2ProfileOf B, then instances of A meet a subset of requirements in B, and requirements in A are all restrictions of requirements in B.
  3. isType3ProfileOf -- if A isType3ProfileOf B, then instances of A meet ALL requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.
  4. isType4ProfileOf -- if A isType4ProfileOf B, then instances of A meet a subset of requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.
  5. isType5ProfileOf -- if A isType5ProfileOf B, then instances of A meet a subset of requirements in B, and A adds additional requirements from other specifications that may be incompatible with B.
  6. uses -- if A uses B, then instances of A meet one or more requirements of B. This is a generic statement that would subsume the other relations (above)

The transitivity rules could be constructed here, but they're tricky.
If A isType1ProfileOf B and B isType1ProfileOf C then A isType1ProfileOf C, is true.

If A isType1ProfileOf B and B isType4ProfileOf C then A isType4ProfileOf C is true...

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

@smrgeoinfo I really like your typology here. It is complementary to the more general statement of typology that I was suggesting for the guidance document. This is the best description of both profile types/relationships and transitivity that I have seen so far.

It seems to me that we have two threads going on that are parallel but have different audiences. One is the world of profiles that exist mainly as documents, such as MS Word documents and PDFs. One could say that these are "old-fashioned and out of date" but they still exist in many communities and are an active part of the community data sharing. Obviously, they require a large amount of human capital to understand and use. They also lack precision, but it is often the case that the data these communities work with is not very conducive to precision. You find this kind of data in the cultural heritage area (libraries, museums, archives) as well as in the crowd-sourcing and open access area as in Wikipedia, MusicBrainz, etc. If you profile within these arenas, you're working with messy data and not much precision. This is similar to the environment that schema.org operates within. These communities can generally go no further than your type 6 in terms of relationships between profiles when they create them.

The other thread is what I would call "precision data" - where closely-aligned communities with a good degree of control over their data and data formats can have reasonably strict rules that can be modeled as formal constraints. These are your 1-5 types. As evidenced by the length of these two paragraphs, my experience is almost entirely in type 6. ;-) However, I see an opportunity here to align these types and provide guidance regarding the profile description elements that are needed to make these types functional. This mainly becomes a definition of this thing called "requirements". I'm interested in whether we feel we can tackle that in our document.

There have been statements that profiles of the type 6 are "useless" or simply do not work. I hope that we can rise above such judgments because we have many real world instances of folks using those types of profiles even though they are not easily subjected to algorithmic validation. We do need to include both worlds in our analysis and deliverable. The trick is going to be how we integrate the two into a single document, but I'm very encouraged that your analysis here may help us navigate that difficulty.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

@kcoyle indeed using the word specification doesnt add anything really which is why i guess no one felt the need to add it originally - but you were also stating that you couldnt readily see the recursive nature which supports both hierarchies and polymorphism inherent in this definition.

It is of course explicit in the profiles ontology - which is another reason a formalism is so crucial to have IMHO

prof:Profile rdfs:subClassOf dct:Standard

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 1, 2018

I am strongly not in favour of creating a formal typology of profiles - I have seen how much pain, confusion and fruitless debate even two levels in the ISO typology of profiles causes.

If a single conceptual model is able to handle all the cases, then lets keep it simple unless we have a driving requirement that cannot be met with that model - for example some restriction that types of profiles need to express that need users to have provided an explicit statement of type, that cannot be directly inferred trivially from the available properties.

To introduce a typology we would need:

  1. driving Use Cases
  2. worked examples
  3. someone willing to do all the work of modelling, documenting and illustrating
  4. a significant debate and proof these things are indeed disjoint.. or at least different enough to be interesting

for example
isType3ProfileOf -- if A isType3ProfileOf B, then instances of A meet ALL requirements in B, and A adds additional requirements from other specifications that are not incompatible with B.

is actually the simple case:

A isType1ProfileOf B,C,...

and "requirements" that do not have mandatory cardinality (in the case of information schemas) can be met by absence, so "ALL" is easily met - and if you do not meet requirements you are simply not a valid profile.

At this stage "partial conformance" is out of scope - profiles support the simple case.
IMHO its a separate (and difficult) piece of work to work out what a partial conformance statement would mean in a Web context - its difficult to see any useful role beyond making documentation a little easier - "this thing is a bit like one of these"

@agreiner

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

I don't mean that all profiles would have an ensuresConformanceTo, only if they happen to do that.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

@Greiner - as above feel free to crate UseCases where conformance is not expected. We need to distinguish and support conformance as per current model - so we must not break that, but another ontology to describe flavours of non-conformance could be defined. Until that is articulated, tested and evidence of implementation available we cannot break the useful, strict, model that matches the Use Cases we have, and engineering practices across multiple platforms. There is currently no equivalent to isNearlyA predicate available in RDF, OWL, XSD, Schematron, Java, javascript, python etc etc that I'm aware of, although SKOS provides "closeMatch" - so you could use that to relate profiles that are similar without breaking the model.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

I don't think it makes sense to have a formal definition of non-conformance much less types of non-conformance. And note that the XSD, Schematron, OWL, etc are generally relations between instance data and a profile, not between profiles. So let's stick with relationships between profiles.

To me the issue isn't how we define non-conformance but how we can talk about profiles without conformance. If "profileOf" requires conformance then we cannot say that profileA is a profileOf standardX unless the profileA defines conformance formalisms. Meanwhile, we've floated the idea that a profile can be any combination of functions, not all of which support conformance. So the issue that I see is not whether conformance between profiles is an option, it's whether we require conformance for something to be a profile. And if something like the DCAT-AP PDF can be considered a profile, can it be used as the subject of profileOf? If it is, then what happens to the conformance requirement? These are pretty factual questions.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

I dont think it makes sense to talk about specifications or standards or profiles without an assumption of conformance. Anything else confuses and complicates the issue immensely, and until we bring it into scope using the established consensus mechanisms it remains out of scope.

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

Been away for a couple of days so coming in late to this discussion. One point that we discussed with the implementers of the EU DCAT-AP was how implementers could create national/local profiles of DCAT-AP. We talked about such local profiles 'extensions of DCAT-AP' and published a guideline for such extensions: https://joinup.ec.europa.eu/release/dcat-ap-how-extend-dcat-ap. The basic idea was that instance data conforming to a local profile would also conform to the European profile, so that instance data from one country would still be able to interoperate with instance data from another country that conformed to another country's extension -- but they might not understand each others' local bits. It would be useful if such a local profile could express this kind of relationship between the local and the higher-order profile. Would this be a type 3 relationship as defined by @smrgeoinfo?

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Nov 2, 2018

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

And I back @rob-metalinkage up too: it makes no sense to talk about profiles without any conformance. That is what they are for.

@makxdekkers see the on point example at https://w3c.github.io/dxwg/profilesont/#eg-hierarchy

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2018

It seems clear to me that DCAT-AP considers itself an application profile, without specifying any particular implementation of conformance:

"The Application Profile is intended to facilitate data exchange and therefore the classes and properties defined in this document are only relevant for the data to be exchanged; there are no requirements for communicating systems to implement specific technical environments. The only requirement is that the systems can export and import data in RDF in conformance with this Application Profile."

The use of "this" in that last sentence appears to refer to DCAT-AP as an application profile (not to mention that it's in the name!). So if we agree on the reading that conformance is assumed but not defined, then DCAT-AP can call itself a profile while being a PDF. Conformance implementation can take place elsewhere or even be unknown to the profile, and it does not have to be co-existent with the profile specification. (I would like to hear from @makxdekkers on this - did I get this right? Or would you like to clarify this? Thanks.)

If that is agreed, then profileOnt provides the way to make the connection between the profile specification and the profile conformance in the case in which they are separate resources.

Note also that your diagram has a DCAT-AP box that has "profileOf" between DCAT-AP
and DCAT. If the DCAT-AP there is not the DCAT-AP that has as its title DCAT-AP then the diagram is misleading. I think we have a lot of definition issues to work out.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2018

+1 that is exactly the interpretation behind the profiles ontology design.

Not sure i understand the last para.. there is only one DCAT-AP being discussed anywhere as far as i can see so i think you are saying in an inside out way that we do have a working definition consistently modelled?

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 3, 2018

I was responding to this in Nick's note:

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

The question is: is the subject in the following triple coherent with the profilesOnt definition of prof:Profile?:

prof:profileOf

This follows from the definition of the domain of prof:profileOf as prof:Profile. So I'm trying to clarify what the nature of prof:Profile is because it isn't clear to me, so I was using DCAT-AP as a concrete example. To me, the DCAT-AP specification expressed as it is in the form of a PDF meets the definition in profilesOnt and profgui documents for profile. If, however, it does not meet the intended usage in profilesOnt then I think we have a problem with our definition of profile and we need to work to reconcile that. (The definition of prof:Profile does not connect to the definition of prof:ResourceDescriptor, and the diagram at https://w3c.github.io/dxwg/profilesont/#eg-hierarchy doesn't clarify that for me.) (I have other questions about the diagrams, but let's clarify this first.)

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

@kcoyle You asked for my view on "Conformance implementation can take place elsewhere or even be unknown to the profile, and it does not have to be co-existent with the profile specification". I must honestly admit that I don't understand your statement, so I am afraid that I can't clarify it.
Can you define "conformance implementation"? Are you making a distinction between a "profile" and a "profile specification"?
The situation with the EU DCAT-AP is that there is a document (draft of latest version at https://github.com/SEMICeu/DCAT-AP/tree/master/releases/1.2/Draft) and a SHACL file that can be used to validate instance data (https://github.com/SEMICeu/dcat-ap_shacl, cardinality and ranges).
Does that help?

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

@makxdekkers Thanks, I realize that this thread has taken quite a turn! The "conformance implementation" is based on terminology in the profiles ontology and I believe it simply means what you say above, which is some code or machine-actionable document that can implement the constraints in the profile. But the main question I am asking is: is DCAT-AP itself (the document of that name) consistent with the definition of prof:Profile?

The first question is "what is a prof:Profile"? The second is: Must a profile include actionable conformance? Obviously, one answer hinges on the other. (Another wording: does conformance here mean actionable code, or can it mean described verbally but not itself actionable?)

If I have X-AP which is a document much like DCAT-AP, but I have no conformance code, is X-AP a profile by the definition in profilesOnt?

I'm trying to clarify the statement above that says: I dont think it makes sense to talk about specifications or standards or profiles without an assumption of conformance. followed by my question of whether DCAT-AP (the PDF document with that title) can be used in a profilesOnt statement:

<iri for DCAT-AP.pdf> prof:profileOf <iri for DCAT>

or if the subject of that triple must be an IRI for a profilesOnt structure, as in the various diagrams.

All of this is triggered by the interaction above:

@kcoyle “...if something like the DCAT-AP PDF can be considered a profile...”

According to Profiels Ont it wouldn’t be, it would be the artifact of a Resource Descriptor. See the on point example: https://w3c.github.io/dxwg/profilesont/#eg-dcat-ap

That was where my confusion began. And now I probably have added to yours. But it is needed to clarify how the profiles ontology can be used and how strict it is in defining "profile".

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

@kcoyle It's an interesting question. I can see a analogy here with Dataset. A similar question could be: If I have a file with data, is that a dcat:Dataset? In that case, no, it isn't; the file is the Distribution of a Dataset.
In the case of profiles, it is a similar situation: the prof:Profile is the 'conceptual' resource, and the specification document is one of the possible serialisations of it, just as the SHACL file is another.
Please note that the files linked from https://joinup.ec.europa.eu/release/dcat-ap-v11 at the bottom of the page are shown under the heading 'Distributions'!
So my answer would be, no, the human-readable document is not the prof:Profile.
The definition at https://w3c.github.io/dxwg/profilesont/#Class:Profile is correct as far as I am concerned: it says a prof:Profile is a "named set of constraints", not a "document containing a set of constraints".

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

And as I see it, the Profile Ontology defines the semantics of prof:Profile, not the English word 'profile', the meaning of which you would look up in an English dictionary.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

@kcoyle: the give-away is that you've referred to a DCAT-AP resource ending in .pdf, viz. <iri for DCAT-AP.pdf>, which is, as @makxdekkers says, a distribution of the conceptual thing, the profile.

So, "Must a profile include actionable conformance?":
No. You could declare a profile like this, using your demo URI:

<http://example.org/catalogue/profile-x> a prof:Profile ;
    rdfs:label "Profile X" ;
    prof:hasResource <http://example.org/catalogue/profile-x/distribution-y> .

<http://example.org/catalogue/profile-x/distribution-y>
    a prof:ResourceDescriptor ;
    rdfs:label "Profile X Guidance Document (PDF)"  ;
    dct:format <https://w3id.org/mediatype/application/pdf> ;
    prof:resourceRole roles:Guidance ;
    prof:artifact <iri for DCAT-AP.pdf> .

So this is s conceptual profile with one ResourceDescriptor which is a PDF document with the role of Guidance. No SHACL-like resources in sight!

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 4, 2018

This is all fine - for folks who are imbued with knowledge of DCAT datasets and distributions. I'm not sure how this plays beyond that environment. So much depends on who we see as the audience for the profile guidance and the profiles ontology. For example, someone with a "physical" profile document (pdf, txt, whatever) but who hasn't encountered DCAT dataset/distribution concepts may find it intuitive to consider that file to be a profile. If we go this abstract/distribution route then we must use the abstraction/distribution distinction in the guidance document. This may narrow the audience for that document and for profiles ontology, making it less likely to be accepted more widely. With my DCMI hat on, I don't see this as desirable. I do see a possibility to create a profile guidance that is parallel to DCAT, and I also see a possibility to create a general definition of profiles that is not directly related to DCAT. However, I think these are two different efforts, and we will need to decide which we will deliver.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

I dont see the problem - its the standard http-Range14 issue - we can just refer to any of the common examples if we feel we even need to address it at all - e.g. hit Wikipedia and it will redirect to a language specific page.

The wording just needs to remind people that a profile can be expressed in many different ways, and some of those may be partial (e.g. some parts can be expressed in SHACL), so the profile is abstracted from its artefacts, this is why we have an abstract model in place already. Thus the issue is a purely editorial one of getting the best wording we can with the effort available.

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

@kcoyle I don't understand. I see no problem with people calling their document a 'profile'. A lot of people will not be interested to formally describe their profile in LD terms, so they have no need to even look at the Profile Ontology. They can even call each of the eight files at https://joinup.ec.europa.eu/release/dcat-ap-v11, 'the profile'.
But: as soon as they want their profile to play in the LD world, they will read the specification of the Profile Ontology and understand what the ProfOnt classes mean and how to describe their physical artefacts. They may still call their document colloquially 'the profile', but they'll know that their document is not the prof:Profile.
The same situation occurs with someone who has a file with data. If that person wasn't familiar with DCAT, he or she may find it intuitive to call that file a 'dataset', and that's fine. It is just that for the description of the file with DCAT, that person would need to read the specification of DCAT and then understand that the file is not the dcat:Dataset.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

@kcoyle said "I do see a possibility to create a profile guidance that is parallel to DCAT, and I also see a possibility to create a general definition of profiles that is not directly related to DCAT. However, I think these are two different efforts, and we will need to decide which we will deliver."

The Profiles Ontology, and the Guidance document, aren't tied to DCAT so we should be creating general definitions of profiles. Having said that, there's nothing that I can see in DCAT's formulation of things that is problematic for profiling so we should also be able to have "profile guidance that is parallel to DCAT" too in so far as Dataset relates to Distributions and Profile relates to Resource Descriptors.

Having a profile abstracted from its artefacts paralleling a Dataset abstracted from its Distributions, as @rob-metalinkage says above, is the flexible, sensible way of modelling things. DCAT makes the split for this purpose.

@kcoyle daid "...someone with a "physical" profile document (pdf, txt, whatever) but who hasn't encountered DCAT dataset/distribution concepts may find it intuitive to consider that file to be a profile.".

Sure, and when not talking about their document with the precision a formal ontology brings, that might be fine. But when they come to formally define things and perhaps when their profile becomes a bit more complex and powerful (e.g. wanting to create a schematron file from the PDF and use the PDF for Guidance, the schematron for Validation) then they abstract the notion of the Profile away from the 'physical' document.

The Geoscience Australia Profile (of ISO19115-1) is a good case in point: the profile used to informally refer to a Guidance document which was then put up in the GA catalogue in DOCX and PDF forms (http://pid.geoscience.gov.au/dataset/ga/122551), so then they had effectively a conceptual Profile (Dataset) and Profile Descriptors (Distributions). Now, GA have put their profile up as a bundle of things: an overview web page (http://pid.geoscience.gov.au/def/schema/ga/ISO19115-1-2014), code lists, schematron files, XSDs etc. The Profiles Ont is able to describe the GA Profile at all stages.

@makxdekkers - agree! We are on the same page here. You posted that as I was typing this out!

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

I agree with @rob-metalinkage that the wording of the document needs to explain that the profile is abstracted from its parts. I don't see that in the current version of the document, and the diagrams do not make that clear to me. Basically, everyone who reads the document needs to come away with this concept, even if they are unaware of the parallel model in DCAT.

@makxdekkers "But: as soon as they want their profile to play in the LD world, they will read the specification of the Profile Ontology and understand what the ProfOnt classes mean..." You are much more optimistic than I am. As is often said, the great thing about standards is that there are so many of them to choose from. That, and the fact that there is no enforcement. However, the key thing here is that the profiles ontology document must be very clear if it is to be used widely. Then users will choose to use it or not, but hopefully those who choose will be using it correctly.

@nicholascar said: But when they come to formally define things and perhaps when their profile becomes a bit more complex and powerful (e.g. wanting to create a schematron file from the PDF and use the PDF for Guidance, the schematron for Validation) then they abstract the notion of the Profile away from the 'physical' document. This brings up an essential question of authority that some of us are very familiar with from the library world. When there is a SHACL document and a ShEx document and a Schematron document and they either conflict or have minor differences, which is the authoritative statement of the profile? When there is a written/verbal document (like DCAT-AP.pdf) and it has aspects that cannot be expressed in SHACL ("mandatory if applicable") which is the authoritative statement? This probably arises less in DCAT because the distributions are all distributions from "a" dataset, meaning that there is probably a parent physical file somewhere (usually) that one can go back to. In the profiles case, it isn't clear if there is an authoritative parent, and the model is much more complex because the parts are not all distributions of the same thing. (I'm assuming that one is not required to have a written document as the foundation for a profile, but any set of artifacts makes a profile.) In fact, with profiles it is much more complex, and reminds me of some library cases. For example, in bibliographic description when you have a translation you want to know what version of the text was the basis for the translation, or if a translation is a translation of another translation. With profiles, if you have SHACL and ShEx validation documents, were they developed independently or was one derived from the other (there are translation programs between them). Without a parent or an anchor for all of the artifacts that make up the totality of the profile you have a lot of uncertainty. Also, you may need more information about the relationship between artifacts. How much this matters depends on the individual case. In fairly coordinated environments this may not have an affect. In the wild web world, like the one that schema.org operates in, usage of artifacts could be error-prone if their exact nature in relation to the content of other artifacts is not clear. That's not an argument against the model, but a caution for developers. Nor is this an argument to create a more complex model (which the library world does, and it's hellish-ly complex). But I think it is important to acknowledge that we are aware of these complexities, and to state a position in relation to them.

@larsgsvensson

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

@makxdekkers scripsit:

The same situation occurs with someone who has a file with data. If that person wasn't familiar with DCAT, he or she may find it intuitive to call that file a 'dataset', and that's fine. It is just that for the description of the file with DCAT, that person would need to read the specification of DCAT and then understand that the file is not the dcat:Dataset.

void:Dataset being an obvious case... (VoID predates DCAT)

@makxdekkers

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

@larsgsvensson

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

@makxdekkers Ah, OK. Thanks for giving me more context!

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

This has largely superceded the "what is a profile" issue - and I think we have a convergence around the abstract model proposed. @kcoyle points out that we still need to work on messaging for some audiences, and as editor I'm always happy to help facilitate proposed improvements in wording - probably need these raised as specific issues in place in the documents to discuss and progress - so the process has to be first see if such issues exist in place, create if missing, then move them towards a proposed improvement.

This issue has done its job by teasing out feedback, supporting a discussion and reaching consensus that we have a position that does seem to make sense. I suggest we close it now.

@kcoyle

This comment has been minimized.

Copy link
Contributor

commented Nov 5, 2018

I believe that issues should be closed when they have been resolved within the document. Until that happens, it should stay open.

@nicholascar

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

@kcoyle in #486 (comment). Yes, indeed, there's potentially many complex things that could be modeled but, like original DCAT, let's get this fairly simple model out there and leave complexity to PROFv2! Profile relation typologies, fine-grained ResourceDescriptor/Profile relations etc. all interesting and difficult but I don't fancy an ontology with many more classes and relations than we have now.

Currently there is no way in ontology land to formally define a profile and its bits, at any level of detail, so this is an improvement, and even if more finessing may be desired, I would hope simplicity will see wider adoption.

@aisaac

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

OK I'm going to be very blunt: what in the discussion in the past three days is about the original topic of this issue?
There was a proposal at #486 (comment)
Is there anything against it?

It is about the name of a property involved in a 'transitive closure' pattern and the axioms defining this property. This is not about profileOf. Actually it really doesn't say anything about profileOf, just as the existence of skos:broaderTransitive didn't say anything about the semantics of skos:broader (https://www.w3.org/TR/skos-primer/#sectransitivebroader). It's just a technical trick to make available a shortcut for a chain of profileOf statements, when such a chain exist, and for the people who are interested in such a shortcut. It doesn't 'pollute' the original profileOf statements at all.
So again is there any objection against the proposal from 8 days ago?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

commented Nov 6, 2018

no - and it was discussed agreed ana actioned - which is why i wanted to close this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.