Closed jkreft-usgs closed 5 years ago
See: https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007 for example feature See: https://www.hydra-cg.com/spec/latest/core/#adding-affordances-to-representations for one potential solution. See: https://docs.google.com/document/d/1YzApMKf1XIW99BMNeWfJ5hNBDnG-wBzEUWL1nfOQ4Ag/edit#bookmark=id.3kuf13nkovzd for meeting notes that created this issue.
See : https://github.com/w3c/dxwg on-going work on content negociation by : https://github.com/w3c/dxwg/tree/gh-pages/conneg-by-ap previous version : https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/
Also this issue, where we punted in ELFIE opengeospatial/ELFIE#115
We should start with the DXWG definitions, not least because their use of 'profile' is consistent with the OGC's. Also our community is well represented in the WG (Rob Atkinson and Nic Carr both editors on the Conneg by Profile draft) and, reading the profile context discussion it looks like we'd just recapitulate the discussion they had.
It seems W3C have taken “profile” as a subset of a (formal) specification. I think we are after a subset of all the possible information available about a real world feature. To me it’s like the real world feature is a book and I’m requesting only the abstract or chapter 1, etc. These are not ‘views’ of the book but a subset of it. Perhaps ‘form’ may be more appropriate than ‘representation’, ‘profile’ or ‘view’.
I agree @abhritchie we should lean on the DXWG work as much as possible. But as Bruce points out, the "profile" definition isn't broad enough for what we want to encompass.
We are talking about a representation of a given non information resource. That representation may conform to a profile of a formal specification but it doesn't have to. I like @bsimons14's suggestion and could get on board with representation form but also like model view for the same reason.
I feel pretty strongly that none of these terms can stand alone. Just like media type is the formal definition for what we would often call format we need more than profile or representation to be clear. re: profile, what we really mean is specification profile.
so... food for thought.
My view is that we should stick to the generally accepted implementation of a resource representation. That is a resource with a specified media-type - negotiated or not. If I understand the issue discussed in the meeting yesterday, the struggle is trying to come up with a term that describes alternate representations (e.g. data, metadata, services, etc...). of a real-world "thing". These are just resources that can be linked back to the real-world thing. They are related resources, not resource representations. Perhaps the confusion is that we are mixing metadata and data resources? In any case, both (metadata, data resources) will have different representations. Am I oversimplifying?
I agree with @jvanulde, and with the second bullet point in the original statement. In my naïve mind, you either have different media types of the same resource (without loss of the structured information, e.g. JSON-LD vs RDFa vs GeoJSON-LD), or you have related resources that are more or less tangential to the original Thing, and their relationship should probably be expressed with rdfs:seeAlso
, other descriptions of equivalence, or with a relationship vocabulary (such as foaf:knows
, foaf:weblog
, foaf:depicts
etc for a foaf:Person
). Different media types of the same resource are readily handled with HTTP content negotiation and ideally (but not necessarily) identified by the same URI; related but different things must have different URIs. Anything else will, in my opinion, deeply alienate web developers.
The remaining difficulty in my mind lies where there is an attempt to represent the same Thing as different media types, but where there is loss of information. For example, some Thing expressed in three dimensions in GML, that cannot be expressed as GeoJSON without loss of a dimension and the projection). Either the GeoJSON Thing needs to be considered a separate resource, or not used at all due to its inherent limitations in expressing the pertinent qualities of the real Thing.
@bsimons14 I'm not sure that analogy works; rather it sounds like you're describing some mechanism of data chunking rather than requesting a representation. If the book is the entire real world entity (non-information resource), then requesting an EPUB or a PDF is more akin to this issue. Each format is an attempt to represent the entire real Thing, yet both fall short of actually delivering you the physical book. (For your purpose as a reader, that's fine, and your preference for EPUB or PDF is probably driven by your reading device and may even be opaque to you as a reader of a book.) Similarly, you could request an EPUB or PDF of Chapter 1 of the Book—also a real Thing, like a free sample—but they still fall short of ripping out the chapter and handing it to you. Chapter 1 is not a representation of the same Thing as the entire book, regardless of physical or electronic "media type". Getting information about a particular book's publisher, or information about the author, or the book's characters requires links to related things from the representation of the book; but the publisher, author and characters are neither the book nor views of the book.
Considering the example @dblodgett-usgs linked (https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007), the Spatial Thing is a hydrometric station. The landing page provides links to, for example, annual statistics and monthly means as different Things (because different URIs). They are identified explicitly with rdfs:seeAlso
. Doesn't that simply make them each a new resource, distinct from the parent resource from which they are linked? They are not "views", "profiles", "models" or "representations" of the original; they are distinct resources that have an identified relationship to https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007. Each of those resources identified by an rdfs:seeAlso
stands alone and for many use cases is perfectly interpretable without dereferencing https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007.
So if we "Need to choose a word that describes different views of the same resource"; I would argue that word is media type or format, and that the corollary is that we must be very generous in declaring Things as distinct resources, while being explicit about their relationships.
Disclaimer: I'm quite new to linked data, ironically having worked as a web developer. So I may be mis-interpreting some aspects of this discussion. I found the idea of a "profile" in our discussion to be very confusing.
Excellent comments. The links in the example @dblodgett-usgs linked (https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007), are different resources. But they all represent a view or subset or ‘something’ of the same real world resource which I don’t think is adequately captured by rdfs:seeAlso. If we have multiple resources of the same real world feature such as a borehole we need a way to identity what each of the resources associated with that feature contains. At a minimum this means what syntax/format (dealt with by content negotiation), what structure/schematic (e.g. GWML2, GeoSciML, O&M), and what subset of the schema (what profile). I’m unsure whether the proposed ‘profile ‘ solutions cover the schematic aspect. Or perhaps a more extensive vocabulary to relate the various online resources?
@bsimons14
I think the 'syntax/format', 'structure/schematic' route will be an emerging trend (see DXWG work) especially if this new 'profile' header parameter comes to life. But, this won't be trivial to set up (we'll comme up to discussions on how a client will know what is available at the other end of a URI -> see https://www.w3.org/TR/2018/WD-dx-prof-conneg-20181218/#listprofileshttp).
If we add the 3rd facet ("what subset of the schema"): that complexifies our common understanding even more and add more questions to the table (ex : are elements from that subset picked from the various profiles available ? is that selection available somewhere (through a URI) ?, ...)
For the sake of moving this discussion forward could we sketch/draw something based on the example (https://geoconnex.ca/gsip/info/swmonitoring/WSC_02OJ007). It will help put word (ex : the 3 facets proposed by Bruce) on the drawings and be sure we understand each other within SELFIE. For example :
I think we are getting somewhere here. Everyone is on to something. I'll offer two things to the discussion briefly though.
1) I think everyone may be overlooking the distinction between "Non Information Resource" and "Information Resource". We are all very comfortable with a URL that resolves to a web page standing in as an identifier for a real-world thing (think an email address as an identifier for a person) -- but the premise of SELFIE is that this practice of indirect identification of real-world features is problematic and we need explicit identification of real world features as Non Information Resources (NIRs).
2) In response to the latest comments on this thread, I don't really think there is a "third facet". The "complete" set of a given specification is just that -- "the complete set of a given specification". It is just as much a profile as any other. I think what we are saying here is that -- for the list of information resources that represent a non-information resource, we have multiple representation forms that would be negotiated via content-negotiation by profile and content formats that would be content-negotiated by media type.
The last thing I think that is critical here is that there is no requirement that a "profile" or a "specification" be described to a specified level of detail. As far as I'm concerned, a NULL profile is a valid default profile that should be assumed to be unique to the resource in question!
Finally, I think it would be very useful for everyone to re-read the activity plan definitions and background -- there's a lot there that we want to build on that we need to keep in mind.
Defer to work on a context for the set of dimensions we want to describe information resource URIs.
I have a resource, and want to be able to share information about it in a variety of different ways.
At the end of the day we will have this distinction of profile and media type -- we will explore how to use it on an info page. Having a standard list of "profiles" is a good goal that we may be able to illustrate the (potential) value of.