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

Two things that our "profiles" are not #976

Open
aisaac opened this issue Jul 2, 2019 · 29 comments
Open

Two things that our "profiles" are not #976

aisaac opened this issue Jul 2, 2019 · 29 comments

Comments

@aisaac
Copy link
Contributor

@aisaac aisaac commented Jul 2, 2019

Wrt Action 342 from the July 2 call, here's a super quick attempt to introduce two "profile" notions that should be excluded from our scope.
Comments are really welcome - I had to rush this as I probably won't have time to work on it between now and next week.

  1. "Syntactic profiles".
    These are variations of the data structure that do not alter its semantics at all. The same properties and classes are used, only their arrangement differs, and the use of abbreviations. The MIME Type does not even change: i.e there can be different profiles of exactly the same data (statements) in JSON.
    JSON-LD profiles are an example of this.
    It is revealing that while JSON-LD has kept the name of its parameter as "profile", the specification focuses more on the term "form".

  2. "Data profiling" as a data analysis activity (cf Wikipedia)
    This activity aims at providing insight into data, by examining what it contains, often producing statistics about it.
    Data profiling can produce listings of classes and properties and even infer axioms that hold for the data that is examined. And it may conclude that data conforms to a given data specification or profile (according to the DXWG definitions for these terms). However data profiles produced by the activity here are post-hoc. The profiling activity works on data distributions (in the DCAT sense) that are given as input and try to reconstruct the data models behind, so to say. It could be that data profiling recognizes that the given data conforms to a pre-existing specification. It could also be happen that a data publisher would use such conclusion to include a new CONNEG option to their portfolio, arguing that the data they serve is compatible with yet another specification. But this is then a by-product of the data profiling process, so to say. Basically data profiling is not prescriptive about what's in the data, while the DXWG profiles and specifications are artifacts that probably always have this ambition.

@aisaac aisaac changed the title Two things that our profiles are not Two things that our "profiles" are not Jul 2, 2019
@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Jul 2, 2019

media type profiles - are a just a type of profile that profiles one specific aspect of a dataset - this is the general pattern that all communities may use a narrower concept of profiling within their domain without creating a broader definition that we must all bow down to..

we still need one broad enough to handle all the use cases of describing what specifications data conforms to, and how these specifications relate to each other in terms of compatibility (e.g DCAT-AP specialisation hierarchies)

a profile is a specification that has a profile role with respect to another specification. Now we need to nail what that role means functionally, and make the simplest and broadest definition we can.

I'm not sure an arbitrary distinction here is a helpful - I agree with Karen's earlier comment "We do, however, want to include profiles that are not written as actionable code". Profiling is a specification activity - so data conforms to a specification which may be profile which relates to one or more specifications - i.e. the relationship between specifications entails further statements about what the data conforms to. It doesnt seem to make sense to split this up as there is a single functional intent, and we really dont care too much about the form of the specifications themselves.

@pwin

This comment has been minimized.

Copy link
Contributor

@pwin pwin commented Jul 3, 2019

Isn't an "application profile" as distinct from the definition #2 from @aisaac a "precondition" or a "stipulation" for the form of the data that is required for its correct processing within the application?

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Jul 3, 2019

@rob-metalinkage are you arguing that media type profiles (well, considering that JSON-LD profiles are within one media type, i.e. they don't specify their own media type)? This would be interesting. I guess I could see this working, but it requires a definition of profile that would probably be too flexible for some people in the group. I mean, I had to retract my one unifying definiton because people didn't want a profile to be "based or not" on another profile, it had to be based on something. JSON-LD profile would bring the same degree of scope extension, if just some JSON-LD forms are not based on a data specification. E.g. asking for the "compacted" form of a DCAT JSON-LD file has nothing to do with DCAT.

As for data profiling, it's not specification, it's analysis of something that's given. I will really stand strongly behind this.

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Jul 3, 2019

@pwin I'm not sure I understand your question but I'll try: an application profile is a data specification, which is indeed expected to be conformed to, so that a given (range of) application(s) can work with the data.

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

@smrgeoinfo smrgeoinfo commented Jul 3, 2019

@rob-metalinkage I agree,

a profile is a specification that has a profile role with respect to another specification. Now we need to nail what that role means functionally, and make the simplest and broadest definition we can.

The relationships tossed out as examples in #963 (comment) are a starter for defining what the roles mean functionally (if I understand your comment!). From the discussions so far, it seems that the defining aspect of a profile is that it has a relationship to one or more existing specifications (base specifications) that might be one of several things: 1) the specification target is the same or a specialization of the target of the base spec 2) one or more provisions are taken directly from the base spec or are restricted in some way relative to the base spec. 3) conformance to the profile implies conformance to the base spec

@andrea-perego

This comment has been minimized.

Copy link
Contributor

@andrea-perego andrea-perego commented Jul 4, 2019

Reading the discussion, I'm still unclear whether we have an agreement on whether profiles are only about semantics (as per @aisaac 's comment, and RFC6906), or they can also be about syntax (as @rob-metalinkage 's comment).

Because of the impact of this distinction on the definition of what is and is not a profile, I think it may be worth having a clear position on this point.

Personally, I would favour the notion that a profile is about semantics only.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Jul 4, 2019

I have added a proposed new Use Case, which I hope helps to untangle what seem to be quite different but legitimate views of documents and specifications. #978

in short, we must accept that a document may contain multiple specifications - and we may treat the set of mandatory requirements as one specification and a set of suggestions as another, and have different notions of what "conformance" means for each - the first step is to recognise these are N distinct "named sets of requirements" (I think I am persuaded to avoid "constraints" as too technical because it looks like we need to extend scope of profiles to a broader concept of specifications, which matches conneg functional requirements.)

I dont think this adds any new requirements to DCAT or Conneg, but does suggest some easy ways to describe the differences in a canonical way in the profiles vocabulary.

@smrgeoinfo

This comment has been minimized.

Copy link
Contributor

@smrgeoinfo smrgeoinfo commented Jul 5, 2019

@andrea-perego I"d suggest that what a profile is about (semantics vs. syntax) depends on the scope of the base specification that is being profiled. If the base spec is a conceptual (semantics only), then the profile will be about semantics. If a base spec is about syntax and usage conventions (e.g. an interchange format like ISO19139, GeoSciML v4), then profiles of that would be about syntax and usage.

@agreiner

This comment has been minimized.

Copy link
Contributor

@agreiner agreiner commented Jul 5, 2019

I think it also likely that people would want to add syntactic constraints to semantics-only specifications by using profiles.

@andrea-perego

This comment has been minimized.

Copy link
Contributor

@andrea-perego andrea-perego commented Jul 5, 2019

So, does this imply that, e.g., application/rdf+xml should be considered a profile of application/xml, etc.?

@agreiner

This comment has been minimized.

Copy link
Contributor

@agreiner agreiner commented Jul 5, 2019

I hope not. That would become pretty confusing for conneg. I think the kind of profiles we are talking about need to be about schemas, not media types.

@pwin

This comment has been minimized.

Copy link
Contributor

@pwin pwin commented Jul 7, 2019

@pwin I'm not sure I understand your question but I'll try: an application profile is a data specification, which is indeed expected to be conformed to, so that a given (range of) application(s) can work with the data.

@aisaac - I'm using this to look at vocabulary that steers us away from the word 'profile' - so 'precondition' or 'stipulation' are the sorts of words that give the characteristics that distinguish the 'application profile'

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Jul 7, 2019

its not likely we'll find any word that hasnt been used in related contexts. IMHO we should just accept that each community may have its own narrow notion of profile (and conformance for that matter) but there is a general sense we can use that covers those cases.

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Jul 9, 2019

I guess we have to try and go both your directions, @pwin and @rob-metalinkage . We can't avoid using terms that are ambiguous, but we can combine them with other terms that have different ambiguities, hoping that the intersection will carry some meaninful semantics.
Anyway this was not the intention for this issue. I was just tasked to present two things that are not profiles!

I think that re item 1 there's been some discussion but in the end (as per @agreiner and @andrea-perego ) it seems we still need to make a difference between our profiles and other constructs which influence only MIME-type specific structures, like JSON-LD profiles (and a reminder: two W3C groups agreed there should be a disjunction here, after two hours of shared discussion).
I see @agreiner 's call for syntactic refinement of semantic specification, but I'm going to play it super-formal on this: if there's no use case, then we can let this go in our way.

Re 2 (profiling as activity) the discussion has stayed where it was in the first discussion between @rob-metalinkage and I.

The bits by @rob-metalinkage and @smrgeoinfo about relationships between profiles and other things seem like another iteration of things discussed elsewhere (and in #978) and which I cannot trivially relate to the basic proposal of this ticket.

@RubenVerborgh

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jul 17, 2019

These are variations of the data structure that do not alter its semantics at all. The > > […]
JSON-LD profiles are an example of this.

If you interpret a JSON-LD document as an RDF graph, than no, its semantics do not change.

If, however, you interpret the JSON-LD document as a JSON document (which is a primary reason for JSON-LD profiles and framing), then yes, semantics do change from the JSON perspective. A JSON key that didn't exist in one JSON-LD profile, can have meaning in another.

Hence, I find the exclusion of JSON-LD profiles artificial.

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Jul 17, 2019

the premise of this is wrong - mime type profiles are a subclass of the more general notion of profile we need. some profiles constrain syntax, some semantics - the only requirement is they fit into whatever notion of conformance a community may be using. I'm happy to consider a MIME type profile within the context of syntactical conformance, and a profile providing a set of suggestions about how to encode a concept within the context of conformance to recommendations. As long as I can claim conformance to something and it mean something useful.

@agreiner

This comment has been minimized.

Copy link
Contributor

@agreiner agreiner commented Jul 18, 2019

If JSON-LD profiles are included in the conneg definition of profiles, then how do users decide which mechanism to use in order to negotiate for a (document that has a) specific JSON-LD profile?

@RubenVerborgh

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jul 18, 2019

They can use both mechanisms; if the server supports profile-based conneg, that takes precedence.

@agreiner

This comment has been minimized.

Copy link
Contributor

@agreiner agreiner commented Jul 18, 2019

Isn't that a bit messy from the point of view of the person (or script) making the request? From a practical point of view, one would have to try both mechanisms before concluding something was not available.

@RubenVerborgh

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jul 18, 2019

From a practical point of view, one would have to try both mechanisms

…simultaneously though. It's the same HTTP request.

So in Accept you list application/ld+json;profile=x,application/ld+json;profile=y, and in Accept-Profile, you list x,y,a,b,c (both with q values if desired).

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Jul 18, 2019

+1 @RubenVerborgh - as you pointed out elsewhere its the nature of limited mechanisms that they can get re-covered by more general ones. Clients can just use the profile negotiation mechanism if they have it - if an information profile implies a MIME type profile as well then its perfectly legal just to ask for the generic MIME type and receive the matching specific MIME type profile. (i.e. you dont have to try both mechanisms if you know the resource conforms to the conneg-by-ap behavioural specification, but if you dont know you are free to try both.

@agreiner

This comment has been minimized.

Copy link
Contributor

@agreiner agreiner commented Jul 23, 2019

" if you know the resource conforms to the conneg-by-ap behavioural specification". There's the rub, eh? By enshrining the non-orthogonal treatment in the new spec, we make that question a perpetual one that people will have to deal with. Since there hasn't been an official spec before this, I'm surprised that we are addressing any kind of legacy behavior. Are there a lot of examples of people building their own conneg approaches that handle JSON-LD profiles as something other than MIME types?

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Jul 30, 2019

@RubenVerborgh @rob-metalinkage I am quite puzzled by your points: the position I'm reflecting here wrt JSON-LD results from plenary discussions with the JSON-LD WG: https://www.w3.org/2018/10/26-dxwg-minutes#x06
And as stated, it seems that they've even acted on this since then, as they've embarked on renaming as "forms" what they used to refer to "profiles":
https://www.w3.org/TR/json-ld11/#forms-of-json-ld
cc @azaroth42

Or maybe we should clarify that the kind of profiles here are in terms of (RDF) semantics? In fact RDF/XML may be argued to have the same kind of variations as can be present in JSON: ie. it's possible to express some statements as an attribute or a (sub-)element. To me a specification that would dictate one or the other form of encoding wouldn't count as a profile, though it may indeed be a rather deep difference in terms of the XML document.

@RubenVerborgh

This comment has been minimized.

Copy link
Member

@RubenVerborgh RubenVerborgh commented Jul 30, 2019

@RubenVerborgh @rob-metalinkage I am quite puzzled by your points: the position I'm reflecting here wrt JSON-LD results from plenary discussions with the JSON-LD WG: w3.org/2018/10/26-dxwg-minutes#x06
And as stated, it seems that they've even acted on this since then, as they've embarked on renaming as "forms" what they used to refer to "profiles":
w3.org/TR/json-ld11/#forms-of-json-ld

There's no contradiction; just different terminology. IETF profiles are constraints on structure and/or semantics; a JSON-LD form is a constraint on structure (over the JSON-LD semantic interpretation).

Or maybe we should clarify that the kind of profiles here are in terms of (RDF) semantics?

RDF profiles are a kind of profile indeed.

To me a specification that would dictate one or the other form of encoding wouldn't count as a profile

That's fine; the IETF definition is as open as possible.

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Jul 30, 2019

@RubenVerborgh ok I think it's a matter of scoping: this issue is about "our" data profiles, which was not chiefly focusing on the IETF one. As you voiced objections here I thought it was about the DXWG data profiles. But if your points were about the wider IETF profiles, then we're good. I may still be puzzled about what the IETF profiles cover (it sounds like it's about everything that can be called 'profile', which seems a bit wide) but obviously that's for another github issue :-)

@larsgsvensson

This comment has been minimized.

Copy link
Contributor

@larsgsvensson larsgsvensson commented Sep 12, 2019

@aisaac We discussed this issue in the CNEG meeting and couldn't figure out if your original issue is resolved or not... Can you give us some hints?

@rob-metalinkage

This comment has been minimized.

Copy link
Contributor

@rob-metalinkage rob-metalinkage commented Sep 12, 2019

communities can decide what they call profiles and make up any conformance rules they like - conneg just provides a means to deliver what they ask for. At this stage this issue does not raise a specific problem, or suggestion regarding the conneg spec itself, and seems to be more about scope of the term profile...

@aisaac

This comment has been minimized.

Copy link
Contributor Author

@aisaac aisaac commented Sep 24, 2019

OK let's try to close this.
As per the discussions in July and the vote on the definition of "profiles" (#963), it appears that "our" definition (meaning the WG definition) is focused on "data profiles".
So the scope of the issue becomes thus to agree that 1 and 2 in the descriptions are not data profiles.

However I'm still unsure whether that solves the matter, especially 1 seems hard to handle. The problem is that we have different notions of "structure" and "semantics". Btw this is also why this ticket was also created, i.e. attempting to use counter-examples so as to avoid producing our own definitions of these very ambiguous terms.

Anyway let's try to see if we can agree...

The discussion we had with the JSON-LD group lead to the conclusion that "our" data profiles are media independent. So JSON-LD profiles would be out of scope. In terms of Conneg as @larsgsvensson put it in this comment, JSON-LD profiles are usable for the profile parameter in Accept, but not for the Accept-profile. I see also this in the Conneg spec in this section. If we all agree on this then we're ok, since "our" (again, that means DXWG's) "data profiles" are these for which we propose to use Accept-profile.

Everyone ok with this?

@nicholascar

This comment has been minimized.

Copy link
Contributor

@nicholascar nicholascar commented Nov 27, 2019

Marking due for closing as thumbs up indicate general agreement and all definitions in the WD have been updated. Even though this Issue is dual tagged for profile-negotiation & profile-guidance, the last conversations are all only about profile-negotiation (viz. discussion about JSON-LD, Accept-Profile etc.) so a new issue can be raised if there is still discussion for Guidance.

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