Profile header or profile link? #11
Comments
|
If I remember the discussion in Amsterdam correctly, the idea was to use the Profile header and the Link header with the keyword "profile" (not |
Then we go against RFC6906, which seems problematic. |
|
Do we know how widely deployed RFC 6906 is? (or put differently, is it really a problem if we propose another solution to the problem RFC 6906 tries to solve if the new solution is better (which I think it is since we can supply more information about the referenced resource, e. g. the combination of media type and profile(s)))? |
|
We'd have to very carefully weigh our options. We should ask @dret if he knows about usage statistics of RFC6906. |
|
OK, can you contact him? |
|
Yes, the ping above should work. |
|
On 2017-04-18 18:24, Ruben Verborgh wrote:
We'd have to very carefully weigh our options.
We should ask @dret <https://github.com/dret> if he knows about usage of
RFC6906.
what exactly is the question? not sure exactly what this is about, but
it seems that it is more about schemas/vocabularies than about profiles.
http://dret.typepad.com/dretblog/2016/05/resource-profiles-and-types.html
was an attempt a while ago to clarify what RFC 6906 is all about, but i
still see it being used in ways that were not intended, using it for
schema/vocabulary identification instead of profile identification.
btw, http://webconcepts.info/specs/IETF/RFC/6906 only defines a link
relation type, and no HTTP header field.
in terms of stats of where and how the link relation type used, i don't
have any that i could share, except for talking to people who are using
it or considering using it.
|
|
Hey Erik, thanks for commenting. Unfortunately, despite your blog post, I (and I assume others) remain in the dark as to what "profile" really is about and what it is not about, despite the RFC, your blog post and your response to my comment to it. I'm not trying to be thick, just plain honest. What would, for example, help is to show what language in the RFC excludes "profile" from being used for e.g. schema. Cheers Herbert |
|
On 2017-04-20 15:37, Herbert Van de Sompel wrote:
Hey Erik, thanks for commenting. Unfortunately, despite your blog post,
I (and I assume others) remain in the dark as to what "profile" really
is about and what it is not about, despite the RFC, your blog post and
your response to my comment to it. I'm not trying to be thick, just
plain honest. What would, for example, help is to show what language in
the RFC excludes "profile" from being used for e.g. schema.
i can try again, but i think i now have a long history of not being able
to explain very well what profiles were designed for. generally
speaking, the work is motivated by the API space and more specifically
by http://dret.typepad.com/dretblog/2016/04/robust-extensibility.html as
a pattern for API design.
the "Meaningful Core Semantics" are established by a schema and its
design for openness and extension. this schema might be something like
HTML or atom (both examples from the RFC). this schema is *not* what is
identified by a profile. it is the schema that establishes the API and
in most cases might be identified by media type.
specific ways of using the "Well-Defined Extension Points" and the
"Well-Defined Processing Model" (which are established by the schema)
might be identified by a profile URI. the profile URI is just a way how
it can be signaled that the API is utilized in a specific way. typically
it is not even necessary to signal it this way, but it may be useful to
do so (examples from the spec: "this feed is not just a feed, it uses
the extension capabilities of feeds in a way that turns them into
podcasts"). note that the schema for a feed (or an hcard HTML page) is
still the atom schema or the HTML DTD. the profile is not identifying a
schema. the media type remains the same as well. being able to surface
the "podcast-ness" of a feed is nothing but a convenience function that
may be more convenient than having to programmatically check whether a
feed is a podcast or not.
|
|
Hi Erik and thanks for your thoughts. Like @hvdsomp, I'm also a bit at odds figuring out exactly what a profile is. The posts you've shared provide some clarification, but still leaves some questions open. I'm particularly interested in your views on the choice of "profile" vs "schema" since you use both terms in your posts. What I want to be able to exchange information on are things like XML Schemas, SHACL shapes or Dublin Core Application Profiles, allowing a server to say that an XML document would validate against a specific XSD document, or an RDF representation (irrespective of serialisation (RDF/XML, Turtle...)) would adhere to the constraints specified in a SHACL or ShEx document. Would you consider the SHACL, ShEx or XSD files to be profiles or schemas? In the first version, the I-D was about "schema negotiation" (cf #1) and later we decided to call it "profile negotiation" instead. Perhaps we need to reconsider that. I've re-opened #1 until we've decided on that. |
|
I would propose to follow the description of a profile from RFC 6906:
And from XML Schema:
Following the above, it seems to me that schemas are a proper subset of profiles. In other words, everything that is a schema is also a profile, but not every profile is a schema. Given that we likely also want to support several JSON scenarios, and that most cases there do not have formal schemas that allow validity assessment, I would opt for "profile". Also, I see no need to restrict us unnecessarily to schemas, when we can also support the wider set of profiles with the same effort. If we want our own definition of "profile", I would (following my SDSVoc contribution) propose something like:
|
|
On 2017-04-24 12:58, Lars G. Svensson wrote:
Like @hvdsomp <https://github.com/hvdsomp>, I'm also a bit at odds
figuring out exactly what a profile is. The posts you've shared provide
some clarification, but still leaves some questions open.
like i said, i seems to have a problem expressing this. one of the main
aspects of profile said very explicitly in the RFC is that it is an
*identifier*, not a link. these are different things.
a profile may be implemented by zero, one, or several schemas.
- things such as IJSON and canonical XML have no schemas, but closely
match the definition of a profile.
- things such as podcasts also have no schema. the schema of a podcast
is still the feed schema.
- some profiles may be defined by a schema. like all schemas, it will
only represent a subset of the meaning of the profile. the profile
identifies the concepts, a schema may be used to link to an incomplete
representation of how they can be defined in some schema language.
- if people care enough they might even have multiple schemas for one
profile, as depending on the schema language, you often can make various
user communities happy, and can represent different aspects of the
profile. in XML land, for example, for quite a while people had DTD and
XSD, or XSD and RELAXNG, which were different schemas, but sometimes
were used to implement the same "profile".
I'm particularly interested in your views on the choice of "profile" vs
"schema" since you use both terms in your posts. What I want to be able
to exchange information on are things like XML Schemas, SHACL shapes or
Dublin Core Application Profiles, allowing a server to say that an XML
document would validate against a specific XSD document, or an RDF
representation (irrespective of serialisation (RDF/XML, Turtle...))
would adhere to the constraints specified in a SHACL or ShEx document.
Would you consider the SHACL, ShEx or XSD files to be profiles or schemas?
schemas. you can define to implement a profile in any of these. or, as
pointed out above, you can implement one profile in various schemas
(which in practice happens relatively often). just think about DSDL and
its (unfinished) vision of "schema pipelines"; that might give you a
good framework of why a profile is just an identifier, and then you can
easily have multiple schemas if that's how you decide to implement your
profile.
In the first version, the I-D was about "schema negotiation" (cf #1
<#1>) and
later we decided to call it "profile negotiation" instead. Perhaps we
need to reconsider that. I've re-opened #1
<#1>
until we've decided on that.
it seems to me that you're mixing things, at least in terms how i see
and use these concepts. you are trying to do profile negotiation, but
you are thinking in terms of "there must be one resource that represents
the profile in a machine-processable way that is the one true
representation of the profile". that is not how the world works in the
places where i come from, and hence this perspective makes things
problematic.
i know that this is a gigantic can of worms, but XMLNS/XSD have the
right framework: concepts are identified by an identifier (a namespace
URI). an XSD schema (or multiple XSD schemas, for that matter, i have
seen many examples of this) then defines a schema that implements that
namespace. what matters is not how you find the schema (that turned out
to be a non-problem in practice, because for security reasons nobody
starts downloading and using random schemas anyway), but how you find
out which concepts are referred to in a document. for that you need the
namespace URI, but *not* the xsi:schemaLocation.
in practice, people outside of closely knit circles always ignored
xsi:schemaLocation. what happens in the vast majority of cases is that
implementations pivot on the vocabulary they see (i.e., the namespace
URI), because that identifies the vocabulary that is being used.
assuming that there is a single true and trusted location where to find
the schema causes major headaches along a variety of axes, and simply
never took off (for very good reasons, i think).
to achieve the biggest impact in practice my suggestion would be to go
for profiles, but to treat them in their RFC 6690 spirit: they are
identifiers only, (and profiles can be implemented by 0-n schemas, but
these outside of the scope of profile negotiation).
|
|
Following the above, it seems to me that schemas are a proper subset of
profiles. In other words, everything that is a schema is also a profile,
but not every profile is a schema.
profiles and schemas are different things. a schema is one possible way
to implement a profile. there are other ways as well.
|
That is not the case, so we should be good then. |
OK, sloppy terminology on my side: the proposal we're discussing here is about profile (or schema...) identifiers, not about links |
I'd say that even if profiles and schemas are different things, we cannot completely ignore the schema negotiation. When a client has requested (and received) a resource it also might need to find a corresponding schema against which it can validate the resource and that requires negotiation, too (e. g. for an XML document to decide if the profile should be implemented by a DTD, an XSD or a RELAX NG document, or for an RDF document if the schema is implemented by a SHACL or a ShEx shape). |
So how about we use the same mechanism for negotiation profiles and schemas? (Given that "a schema is one possible way to implement a profile.") |
|
On Apr 24, 2017, at 16:08, Lars G. Svensson ***@***.***> wrote:
OK, sloppy terminology on my side: the proposal we're discussing here is about profile (or schema...) identifiers, not about links.
i think you have to ask yourself what scenario you want to support: if for example from the profile RFC you are looking at the podcast, there is no schema. so being able to negotiate schemas wouldn't help. if you want to be able to negotiate profiles that might have multiple schemas, being able to negotiate schema identifiers wouldn't help either.
and to be honest, i have a hard time imagining use cases where schema negotiation would be useful. schemas are just implementations that should be able to be changed or switched without affecting what concept they implement.
either way: start with these use cases, and only then think about terminologies and what kind of specs you might be able to build on.
|
|
On Apr 24, 2017, at 16:41, Ruben Verborgh ***@***.***> wrote:
So how about we use the same mechanism for negotiation profiles and schemas? (Given that "a schema is one possible way to implement a profile.")
how would that reflect situations where the number of schemas fir a profile is != 1, or where different resources might use different schemas to implement a profile?
|
The idea is that multiple profiles/schemas can be indicated. |
|
On Apr 24, 2017, at 16:27, Lars G. Svensson ***@***.***> wrote:
I'd say that even if profiles and schemas are different things, we cannot completely ignore the schema negotiation. When a client has requested (and received) a resource it also might need to find a corresponding schema against which it can validate the resource and that requires negotiation, too (e. g. for an XML document to decide if the profile should be implemented by a DTD, an XSD or a RELAX NG document, or for an RDF document if the schema is implemented by a SHACL or a ShEx shape).
as mentioned earlier: on the web, few clients will trust schema links and download and use schemas. that's s huge security issue. and quite a number of languages have schema hints (DTD and XSD for example).
if there is significant demand, maybe a generic schema hint/link might help. i think there were several proposals over the past decade, but they all died. imho the reason is that clients almost always use local info to validate. i've never ever seen a production system blindly loading schemas at runtime and then using them.
my suggestion: wait and see if this really is needed outside of tightly coupled communities.
|
|
On Apr 24, 2017, at 17:22, Ruben Verborgh ***@***.***> wrote:
how would that reflect situations where the number of schemas fir a profile is != 1
The idea is that multiple profiles/schemas can be indicated.
how would you know which ones are profile identifiers and which ones are schema links? per RFC, multiple profile URIs mean that multiple profiles are signalled as being present by using multiple identifiers.
|
The assumption is that the client has them hard-coded.
+1 |
|
On 2017-04-24 17:28, Ruben Verborgh wrote:
how would you know which ones are profile identifiers and which ones
are schema links?
The assumption is that the client has them hard-coded.
what do you mean by this? how would a client know if it encounters an
unknown URI if this is a profile identifier it does not know or a schema
link it can follow to find a schema resource?
|
With the current design, it would not. We can add this to requirements (#16) if this is a necessity. |
|
On Apr 24, 2017, at 18:32, Ruben Verborgh ***@***.***> wrote:
how would a client know if it encounters an
unknown URI if this is a profile identifier it does not know or a schema
link it can follow to find a schema resource?
With the current design, it would not. We can add this to requirements (#16) if this is a necessity.
i must be missing something if that's something that seems like an optional extra.
|
|
The current scenario is:
So clients know what to expect. |
|
On 2017-04-25 14:28, Ruben Verborgh wrote:
A "profile" could also signal, for instance, the presence of a certain
key/value pattern in a JSON document. It could also be HTML with a
certain microformat. It could be many, many things, only a couple of
which are specific to RDF (certain vocabularies, certain JSON-LD frame).
the problem is the different perspective on what a profile is. iff you
have in mind to use profiles in their RFC 6906 flavor, then the
mechanism would be an optional hint. it would tell the server "i'd
prefer that specific profile if that is applicable to the resource i am
requesting and you're capable of producing it for me. if not, feel free
to ignore it and send me whatever you think is appropriate. the media
type will make sure we're still on common ground."
|
|
Yes, that's what we aim to do. |
|
On 2017-04-25 14:34, Ruben Verborgh wrote:
Yes, that's what we aim to do.
i sense a disconnect between what you're saying and what lars is talking
about. maybe it would be good to clarify how this mechanism is supposed
to be useful and to work on the web in general.
|
+1 (that's why I use XML examples)
JSON is definitely a use case (particularly since Ruben's talk in Amsterdam was titled "Your JSON is not my JSON". The reason I use XML examples (with profiles implemented as DTDs, XSDs and RELAXNGs) is simply that I don't know enough about the capabilities of JSON Schema. |
|
On 2017-04-25 16:09, Lars G. Svensson wrote:
JSON is definitely a use case (particularly since Ruben's talk in
Amsterdam was titled "Your JSON is not my JSON". The reason I use XML
examples (with profiles implemented as DTDs, XSDs and RELAXNGs) is
simply that I don't know enough about the capabilities of JSON Schema.
sorry for being a broken record, but just to make sure we keep the eye
on the prize: XML and DTD/XSD/RELAXNG do not have the same relationship
as media types and profiles. DTD/XSD/RELAXNG are vocabularies (defined
in specific schema languages) based on a specific metamodel (and as you
pointed out, just getting any XML isn't going to cut it if you depend on
a specific vocabulary being used). profiles are constraints on
vocabularies (constraining/extending them) and you always get the same
vocabulary, with or without profile. the profile is just a "style" of
using it.
|
My vision is that profile negotiation works just as negotiation on mediatype ( Here, |
What I hear is that my suggestion is more tied to what you call "schema" than to "profile". Is that correct? |
|
On 2017-04-25 16:30, Lars G. Svensson wrote:
sorry for being a broken record, but just to make sure we keep the
eye on the prize: XML and DTD/XSD/RELAXNG do not have the same
relationship as media types and profiles. DTD/XSD/RELAXNG are
vocabularies (defined in specific schema languages) based on a
specific metamodel (and as you pointed out, just getting any XML
isn't going to cut it if you depend on a specific vocabulary being
used). profiles are constraints on vocabularies
(constraining/extending them) and you always get the same
vocabulary, with or without profile. the profile is just a "style"
of using it.
What I hear is that my suggestion is more tied to what you call "schema"
than to "profile". Is that correct?
probably. i think "vocabulary" might be a bit more neutral term because
it is less tied to the implementation nature of a schema.
what i am wondering: apart from RDF, do you see use cases (by which i
mean actual problems perceived in running systems)? i have never
encountered anybody who wanted this two-level approach of being able to
say "i want JSON, and i also want this vocabulary", or "i want XML, and
i also want this vocabulary".
either people use specific media types to do this if they feel the need,
or they use generic media types and are content that their APIs happen
to use certain vocabularies, and that's an implicit coupling they're
willing to accept.
if people care about content negotiation, they seem to be content to do
it on the media type level. once again, either they negotiate on
specific media types, or on the generic ones and then the vocabulary is
implicit in the API.
i guess the only use case i can come up with if people wanted to
negotiate on both levels:
- their API supports various metamodels such as XML and JSON.
- they also support various vocabularies in each of these metamodels.
i have never seen anybody asking for this when they designed an API.
|
|
On 2017-04-25 16:29, Lars G. Svensson wrote:
Originally, I intended those profiles to be applicable to specific
media types but having the profile as an abstract model that has
specific implementations in specific schema languages is fine, too,
profiles make no statement about the fact whether they are tied to one
specific media type or schema, or not. that's something that the people
minting the profile URI can decide.
as long as we can get from the profile to the schema.
not in any way supported by the profile spec. and as discussed earlier,
profiles are not necessarily implemented by a schema. they may be
defined in prose, for example. and that's fine, too.
|
|
On Tue, Apr 25, 2017 at 5:39 PM, Erik Wilde ***@***.***> wrote:
what i am wondering: apart from RDF, do you see use cases (by which i
mean actual problems perceived in running systems)? i have never
encountered anybody who wanted this two-level approach of being able to
say "i want JSON, and i also want this vocabulary", or "i want XML, and
i also want this vocabulary".
This is actually extremely common in applications in the realm of digital
libraries, scholarly communication, cultural heritage where a wide variety
of widely used XML-based metadata vocabularies exist to describe resources.
AFAIK, these typically don't have dedicated MIME types; they just use the
generic application/xml. The need to request a specific vocabulary is so
prominent that the OAI Protocol for Metadata Harvesting, spec-ed between
2000 and 2002, and still extremely widely used today, has a request
parameter to express the metadata vocabulary that a client desires. See
e.g. http://www.openarchives.org/OAI/openarchivesprotocol.html#GetRecord.
Cheers
Herbert
… either people use specific media types to do this if they feel the need,
or they use generic media types and are content that their APIs happen
to use certain vocabularies, and that's an implicit coupling they're
willing to accept.
if people care about content negotiation, they seem to be content to do
it on the media type level. once again, either they negotiate on
specific media types, or on the generic ones and then the vocabulary is
implicit in the API.
i guess the only use case i can come up with if people wanted to
negotiate on both levels:
- their API supports various metamodels such as XML and JSON.
- they also support various vocabularies in each of these metamodels.
i have never seen anybody asking for this when they designed an API.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#11 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADojAz9z__V2sEhF7aBy6eU6JLvsaWsAks5rzhOdgaJpZM4M913D>
.
--
Herbert Van de Sompel
Digital Library Research & Prototyping
Los Alamos National Laboratory, Research Library
http://public.lanl.gov/herbertv/
http://orcid.org/0000-0002-0715-6126
==
|
I think (but I'm not quite sure) that the use case that @dvh submitted yesterday (cf #17) goes in this direction. The spatial data is available in several formats (including GML ( A side note: GML is available in different flavours (that they call "profiles" as opposed to "application schemas"), too, cf. https://en.wikipedia.org/wiki/Geography_Markup_Language#Profile |
OK, my original use case comes from RDF and that's where I have an itch to scratch. In the DNB, we have (for historical reasons) two services publishing data about the same authority entities (people, places and things). One is a "traditional" linked data service (LDS) using content negotiation to serve html, turtle and further RDF serialisations. The canonical URIs we mint for our entities resolve to this service and all RDF serialisations it offers use the same data model. The other service (EntityFacts) offers a beefed up version of the same data, enriched with images, further links etc. and originally only served JSON that later was made to JSON-LD. The URIs (really URLs) and the content model of EntityFacts are different from that of LDS. We also have a similar issue with two bibliographic formats (DINI-KIM and BIBFRAME), so it isn't specific to just one type of data. Since we want to use the LDS URIs as the entry point to all our services, the goal is to integrate EntityFacts into the LDS. That would, however, mean that we need a way for the client to specify if they want the LDS format or the EntityFacts format (or profile, or schema, or whatever). That's why I wrote this spec and yes, it was heavily geared towards that use case. Then I got the feedback that the spec shouldn't be too geared towards RDF so I started to make it more abstract. And as Herbert wrote, there are non-RDF use cases for this from the cultural heritage domain. |
Yes, profiles defined in prose are fine. But to perform validation or build interfaces (e. g. Java XMLBeans) we need an actual schema, too. That means that we need a way to get from the profile to the schema. If that's not part of the profile spec then we need another solution. |
|
On 2017-04-25 20:03, Lars G. Svensson wrote:
Yes, profiles defined in prose are fine. But to perform validation or
build interfaces (e. g. Java XMLBeans) we need an actual schema, too.
why is that? if a profile is defined in prose that's what you have.
you'll have to write code implementing that prose. you might prefer to
have a schema and if you have the energy and skills you could write one
yourself, but that doesn't change the fact that the profile is not
defined by a schema.
That means that we need a way to get from the profile to the schema. If
that's not part of the profile spec then we need another solution.
i think assuming that profiles always have one authoritative schema
associated with them is not an assumption backed by how things work in
practice. profiles have to be identifiable. that's it.
|
I'm not saying that the schema defines the profile, I only say that for some uses we need a schema. And while the user could write a schema I'd say that if the profile publisher also publishes a schema that implements the profile, that would improve interoperability.
I'm not assuming that profiles always have one authoritative schema. But it would be helpful for profile users if there is a standardised mechanism that allows them to find schemas associated with a certain profile. That could be done using the (that would require the registration of the relation type "schema", but that should be easy; I find it more worrysome that I couldn't figure out a way to say that the first schema is an XSD document, the second a RELAX NG, the third uses SHACL (in Turtle) and the fourth ShEx (in JSON-LD)). |
|
On 2017-04-26 10:33, Lars G. Svensson wrote:
I'm not saying that the schema /defines/ the profile, I only say that
for some uses we /need/ a schema. And while the user /could/ write a
schema I'd say that if the profile publisher also publishes a schema
that implements the profile, that would improve interoperability.
you may need a schema, but how to find it is a different matter. profile
URIs are identifiers. so logically speaking, you would need to find the
specification document for the profile, and then see if that contains
any authoritative schema. markus lanthaler had similar questions and
concluded that a profile registry would help with making profile specs
easier to find. the current contents of that registry speak for itself.
https://www.iana.org/assignments/profile-uris/profile-uris.xhtml
but that doesn't mean that the idea itself doesn't have merit. only that
maybe a central registry isn't what's really needed here. but come to
think of it, profile URIs are a web concept and with or without registry
should be the kinds of things people care about when they manage their
API landscape. adding to web concepts!
http://webconcepts.info/concepts/profile-uri/
I'm not assuming that profiles /always/ have one authoritative schema.
But it would be helpful for profile users if there is a standardised
mechanism that allows them to find schemas associated with a certain
profile. That could be done using the |Link| header, too:
that's assuming there's a standard way to first find anything *from a
profile URI*. there isn't. it's just an identifier.
(that would require the registration of the relation type "schema", but
that should be easy; I find it more worrysome that I couldn't figure out
a way to say that the first schema is an XSD document, the second a
RELAX NG, the third uses SHACL (in Turtle) and the fourth ShEx (in
JSON-LD)).
the schema link relation was suggest many times, but apparently there
never was enough momentum to really get it spec'ed and registered. i
find that one of the more promising ideas (but quite different from a
profile). if you think that would be worth pursuing, i'd be willing to
help.
regarding the missing schema language media types: that's indeed a bit
unfortunate and part of the general problem that many spec authors don't
think about (and aren't encouraged when the specs go through review
processes) how their vocabularies can be identified on the web level.
So what I'm trying to say is that we need a standardised mechanism to go
from a profile document to associated schemas. A document talking about
how to use that would then say something like "Profile publishers MAY
want to link from their profile documents to associated schemas. If they
do so, they SHOULD use the standardised mechanism". So I'm not saying
that everyone has to do that. I'm only saying that we if someone wants
to do that, we should give guidance on how to do that.
as a starting point you're assuming that (a) you can find a "profile
document" given a profile URI, and (b) there is such a thing as "a
profile document". both of these assumptions are not true given the
current state of things.
|
|
@larsgsvensson wrote:
Yes, that's correct, except right now the spatial data is only available in JSON (as embedded GeoJSON). However for the statement of @dret:
I don't think CRS negotiation has anything to do with a vocabulary. I just want to tell the server which CRS I prefer, just like using the |
|
On 2017-04-26 12:08, Dimitri van Hees wrote:
I don't think CRS negotiation has anything to do with a vocabulary. I
just want to tell the server which CRS I prefer, just like using the
|Accept-Language| to tell the server which language I prefer, apart from
the mime-type returned.
* brief detour but because this issue is dear to my heart: *
please keep in mind that in the recent RFC for GeoJSON CRS selection has
been removed; only WGS84 is supported. the reason for this is exactly
what we've been discussing in this issue (and what GeoJSON has
experienced as painful interop issues before the RFC was published): CRS
is not a profile-like thing because using different CRS means complete
incompatibility at the very basic level of GeoJSON.
https://tools.ietf.org/html/rfc7946#section-4
|
|
I know, this is exactly the reason why I came here :) |
|
On 2017-04-26 13:51, Dimitri van Hees wrote:
I know, this is exactly the reason why I came here :)
But as we both agree that CRS is not a profile-like thing, should we
conclude that my challenge can't be solved using Profile negotiation?
i would say so. in particular because if you use RFC-GeoJSON, there is
no such thing as CRS selection/negotiation anymore: it's WGS84 only.
|
|
About the GeoJSON RFC I'm glad this is also part of it, otherwise we couldn't use GeoJSON at all:
In my interpretation this means that arrangements between clients and servers about the CRS being requested/provided are no part of the GeoJSON RFC but should be made somewhere else, e.g. with request/response headers. @lvdbrink, seems like OGC/W3C needs to come up with an alternative anyway ;) |
|
On 2017-04-26 14:11, Dimitri van Hees wrote:
However, where all involved parties have a prior arrangement,
alternative coordinate reference systems can be used without risk of
data being misinterpreted.
In my interpretation this means that arrangements between clients and
servers about the CRS being requested/provided are no part of the
GeoJSON RFC but should be made somewhere else, e.g. with
request/response headers. @lvdbrink <https://github.com/lvdbrink> seems
like OGC/W3C needs to come up with an alternative anyway ;)
i intensely disliked this language in the spec when it was proposed. it
assumes that there is such a thing as a "safe context" where you can
still weasel your way around the CRS issue. i think that's partly
unrealistic self-delusion and partly the political compromise to still
allow (but refuse any responsibility for) alternative CRS. but we're
getting seriously off-topic here... ;-)
|
|
True, I'm off to https://github.com/w3c/sdw ;) |
Indeed not very much in there...
Yes, I shouldn't assume that things are as webby as they should be... If the profile URI is e. g. a URN, then there isn't much to do (except perhaps trying to use the IANA registry), but if the profile has an http URI and there is a document available on the web, then it's at least theoretically possible that the publishers can use a standardised way to point agents at schema definitions.
Let's see where this spec takes us and then we can decide.
Do you think there is a solution to that problem at all or is everything lost already? |
|
BTW, I just saw in the PR for Linked Data Notifications that they use the NS Document for ActivityStreams as a JSON-LD profile URI, adding it to the media type in the Content-Type headers Cf. https://www.w3.org/TR/2017/PR-ldn-20170321/#sending-notification-request. To me, this feels a bit weird since the namespace document defines a term "profile" but never says that it is a profile (nor what restrictions it imposes...) |
|
On 2017-04-27 10:00, Lars G. Svensson wrote:
that's assuming there's a standard way to first find anything /from a
profile URI/. there isn't. it's just an identifier.
Yes, I shouldn't assume that things are as webby as they should be...
not every identifier is a link. that's very webby. use links when you
want to link. use identifiers when you want to identify. two different
tools for two different goals.
regarding the missing schema language media types: that's indeed a
bit unfortunate and part of the general problem that many spec
authors don't think about (and aren't encouraged when the specs go
through review processes) how their vocabularies can be identified
on the web level.
Do you think there is a solution to that problem at all or is everything
lost already?
you could write up drafts for registering specific schema language media
types. maybe that's actually a worthwhile thing to do, i had the same
issue with XSD many times.
for the specs still under development, just raise issues with their
editors. but then again, for the RDF-based ones, minting media types is
not something these communities ever do (unless there's a new RDF
serialization), so you might get some resistance to this idea. for other
communities i'd say they probably are open to the idea, but getting
enough momentum behind these drafts would take quite a bit of energy and
persistence.
|
|
On 2017-04-27 10:12, Lars G. Svensson wrote:
BTW, I just saw in the PR for Linked Data Notifications
<https://www.w3.org/TR/ldn/> that they use the NS Document for
ActivityStreams <https://www.w3.org/ns/activitystreams> as a JSON-LD
profile URI, adding it to the media type in the Content-Type headers
|POST /inbox/ HTTP/1.1 Host: example.org Content-Type:
application/ld+json;profile="https://www.w3.org/ns/activitystreams"
Content-Language: en |
Cf.
https://www.w3.org/TR/2017/PR-ldn-20170321/#sending-notification-request. To
me, this feels a bit weird since the namespace document defines /a term/
"profile" but never says that it /is/ a profile (nor what restrictions
it imposes...)
well. JSON-LD took the profile concept and ran with it. to my mind, they
are misunderstanding and misusing it in the same way that has started
our long conversation here. but they still wanted to do it this way and
did it.
|
Thinking of it, would you agree that XSD could be seen as a profile of XML? The specification does add syntactic and semantic constraints...
The upcoming ODRL vocabulary specification (soon going to CR) also talks about how to create and document profiles and I think they've got it right. They could serve as an good use case since they specify three different encodings of their model: RDF/OWL, XML and JSON-LD. |
|
On 2017-04-28 14:35, Lars G. Svensson wrote:
you could write up drafts for registering specific schema language
media types. maybe that's actually a worthwhile thing to do, i had
the same issue with XSD many times.
Thinking of it, would you agree that XSD could be seen as a profile of
XML? The specification does add syntactic and semantic constraints...
i think we're going in circles a bit ;-) XSD is a language with its own
semantics. it just happens to have an XML serialization, but that
doesn't make it a profile. it just means that there is a schema for it
(the wonderfully named "schema for schemas") that you can use if you
want to understand how the XSD vocabulary is serialized in XML.
what matters for XSD is not the XML level at all. it's what you could
call the "XSD infoset", i.e. the model that is expressed via an XML
serialization. in a previous life i even devised a non-XML syntax for
XSD because the XML syntax annoyed me to no end:
https://www.xml.com/pub/a/2003/08/27/xscs.html
for the specs still under development, just raise issues with their
editors. but then again, for the RDF-based ones, minting media types
is not something these communities ever do (unless there's a new RDF
serialization), so you might get some resistance to this idea. for
other communities i'd say they probably are open to the idea, but
getting enough momentum behind these drafts would take quite a bit
of energy and persistence.
The upcoming ODRL vocabulary specification (soon going to CR) also talks
about how to create and document profiles
<https://www.w3.org/TR/odrl-model/#profile> and I think they've got it
right.
thanks for that link! yes, ODRL is actually talking about profiles as
defined by RFC 6906: these profiles can both constrain and extend the
underlying ODRL model. any resource using the model *is* a proper ODRL
resource and can be processed as such; the profile simply indicates the
specific ways in which this ODRL resource is using the language.
They could serve as an good use case since they specify three
different encodings <https://www.w3.org/TR/odrl-vocab/#encodings> of
their model: RDF/OWL, XML and JSON-LD.
nice. and in their case it probably would make a lot of sense to
identify the profile independently of the ODRL serialization. after all,
the profile talks about how ODRL is used, and not how it is serialized.
|
Should entity bodies be described by:
a
ProfileHTTP header?a
LinkHTTP header with aprofilerelation?both?
The text was updated successfully, but these errors were encountered: