Core Media Type Resources

-> Resource

To avoid misunderstanding, I would rather "are not required"

Am I allowed to store a csv files without listing it in the manifest if I only use it from a script? I did not even realize that was that case. But would that work if a RS was using streaming? I thought one of the advantages of having a manifest is to allow streaming...

Just a food for thought: wouldn't it be a better style to use a neutral form? I.e., "Because the user controls" instead of "Because we control"

I am not sure this is well formulated. The specification does not require, but implementation does require a bunch of particular technologies. I think the intention here is to say something like "This specification does not depend on any particular technology..."

I do not understand this statement. The DID subject is defined as:

The entity identified by a DID and described by a DID document. A DID has exactly one DID subject. Anything can be a DID subject: person, group, organization, physical thing, digital thing, logical thing, etc. The document cannot contain a person…

Strictly speaking, they are not. They are URI-s and there is a thing called DID URL…

This is only an abstract, but it should still be precise…

DID or DID URL?

If DID URL is used, then the subject and the resource will be different. And that I find problematic.

This should be SHOULD NOT or maybe MUST NOT (my preference).

Well, not exactly. If, e.g., the item's property is 'name', but the value is a simple string, then it should be turned into a LocalizableString with that value

We should probably refer to the WebIDL here

At the moment we say it must be schema.org and the pub-context in this order. I guess this is what we ought to say here as well.

This means we expect DID implementations to include a full-blown JSON-LD 1.1 implementation.

Just wonder whether this should be elaborated upon. For examples, processing should normatively defined on the flattened form, or something like that.

What does that mean? A DID can refer to a DID document, which is a JSON-LD with some goodies, but is it also usable to refer to any type of document on the Web?

What is normative and what is not in this section? The reference to non-standard documents (proof, signatures) is a source of a problem

Linked Data Proof is a CG document, not a standard. Ie, MUST cannot be used in this context...

shouldn't there be a standard "authorization" and/or "delegation" term defined for the DID document to separate them from, say, "authentication"?

Which community?

The status of this registry is unclear; the reference is a CG note. For this requirement to be normative we will have to settle the status of the registry, too.

(Setting up and maintaining registries is a point of discussion in the W3C team, relevant for this case, too.)

At this moment the context does not exist (which is of course o.k.), which also means that the final URL for it is pending. (Personally, I would prefer, for consistency with other specs, to use https://www.w3.org/ns/did)

Note that this example is valid if an empty method-specific-id is allowed (issue 198)

(Same note is valid for a number of examples later, too.)

This depends on the hash link draft (which, in turn, also depends on a separate ietf draft) which are not (yet?) standard. This means that the "hl" parameter name cannot be normative.

hm. da = dA, right?

It is probably more than 160 bits for Ethereum... (but I am not sure)

For ethereum: a variant of SHA3 is used (Keccak)

I agree it is a bottleneck, not that this is the main one. Formalizing one's thoughts in something like RDF is simply way too hard, even for people in the formal world. We just cannot expect this to happen...

Would it be possible to have ontologies that cover every aspect of human life that may be subject of science? That looks like a (very) tall order...

I wonder whether this is true... maybe true in exact sciences, but less convincing in "soft" sciences (history, sociology, psychology, but even in some areas of medical sciences...)

There is work on canonical RDF (and, related to that, signature), partially deployed but badly documented. We do not need a workshop on this, but get together the 2-3 existing approaches to see if they can be reconciled. There is a meeting planned at TPAC on this, brining this to a separate workshop would just slow down things.

NoSQL people often frown upon vocabularies. Have these as a separate workshop???

This is even worse than before: it is a HUGE area enough for its own workshop. Temporal reasoning, fuzzy logic or logic with uncertainty: there were workshops before as well as incubator groups which did not lead to tangible plans. Maybe it is time to look at this again, but with again a separate workshop!

Do we have Google & Microsoft on board? Without them this is not really meaningful for us. Also, the complexity here is way beyond what this workshop can handle

This section contains enough material for a full workshop!!!

Can we use a different term? With a separate Web annotation spec plus the term of linked data, it is very misleading...

How can I express several named graphs with a shared context? Like TriG?

We may want to remove this as a formal reference (for now at least): the PWP document is so utterly out of sync...

Add to the list: Marcos, Mike Smith, and Hadrien...

Let us not duplicate requirements...

Can we put a more Indian sounding name here?

If we add a reference to ONIX, as proposed elsewhere, I wonder whether this is a new requirement or whether it could be subsumed by an existing one

Isn't this expressed by the previous two requirements, in the technical sense at least?

Same comment as before...

I agree that this requirement should be emphasized, but I would not use it as a formal requirement (as Req 25). Those requirements are used in references, listed in the table at the end of the document, can be used by external documents: we should avoid overlaps.

Alternatively, we should move this as an explicit use case into the relevant section

We may want to add a use case to ensure that, say, publishers have a possibility to include, or include a reference to, major industry standard metadata to publications, e.g., ONIX data

Isn't this one subsumed by 5.1?

I wonder whether these two are not, fundamentally, the same use case: a time range used to limit the access to a publication

I am not 100% sure that is true. The second half of the sentence is, but whether that is accomplished through a single file or not is probably irrelevant for Ahmed (as long as it is easily done).

What does "(technically)" stand for here?

I think this requirement should move to the previous section. This is, fundamentally, a user requirement and not an implementation one

We may want to re-formulate these following the 'personal use case' style. Or can they be removed altogether?

Is this, in its current form, an essential requirement? Isn't it better to push it down somewhere? After all, there are also overlaps with 3.3 (Constituent Resources) which is already fairly elaborate

Why having removed the use case on device independence? The idea was to have a (albeit possibly simple and obvious) use case for each of the horizontal aspects listed into the explanation text

Does it mean that I cannot store the SW somewhere on the Web, separately from my publication?

This, of course, can be dynamic, and can get the list from a manifest file (for example)

Absolutely. It is ironic that we put annotation to a paper, and we cannot do it for publications in general... That papers online are, most of the time, just a frozen, digital version of a printed paper, and none of the possibilities for, say, interacting with data, 3D visualization, etc, are used... And the list of examples would be very long.

See my comments above: all these should be recognized parts of a scientific career, part of one's assessment. Otherwise it won't happen.

True. But that requires a different views in what constitutes scholarly communication, what is accepted as such by those who assess researchers. Publishing scientific data, scientific software, participating in the creation of patents or international standards, etc: these should have an equal value to traditional publications. We are not yet there...

I do not really believe that is a separate issue; it is the issue, referred to above, of the restricted, subscription based access to scholarly content. On the other hand, scholarly communication is not the only reason why these types of cooperations are difficult, the issues go beyond the publication problems.

Ekkora baromság... mintha a 70's évek retorikáját olvasnám a gonosz kapitalistákról...

This did not really work out:-( The last activity on this goes back to 2011.

Did we systematically do that? Can we? If such a listing is based on somebody collecting these data and adding there manually, it would soon become a bottleneck and would be lost when the person moves on to other areas (I have experienced this myself). Maybe a more distributed/social approach, involving the community as a whole, would be a better match.

I would add IDPF to the list, due to their development of EPUB. In general, I believe that an explicit adoption of EPUB by the scholarly community should be promoted: it looks like an ideal way to provide offline versions of publications without the downsides of PDF.

Just an idea: it is still a matter of discussions and, in some way, competition on what kinds of services scholarly Journals (or proceedings) on the Web should provide. There are some great examples (F1000, Plos, PeerJ; Utopia although bound to PDF) but there is probably lots of wheel reinventing is happening. Of course, competition is good, but documenting some sort of a "minimal" set of services and possibilities may make the development of new Web Journals easier. These are sometimes presented at our conferences, but we may need more.

There was an idea of having our own "Web Publication"; maybe that could serve as a showcase, cooperating with various tool developers to turn it into one.

The data citation work is a major success. The software citation WG is, crudely speaking, a flop: nothing is happening in that group. I believe that WG should be stopped and/or new people should be found to move that forward, because we cannot afford keeping such a lame group. (The work itself would be more important than ever!)

Similar "citation" issues may also appear in other areas (workflows, video or audio objects, living organisms like bacteria, etc). We should make a systematic overview on where such work would be needed and concentrate on those.

I believe this goes back to the fundamental work to be done as part of the concept of RO-s, it should not be taken separately. Such a work should be done with a clear proof of usage and interest for other developers (there has been too much work concentrating on RDF/OWL without any tangible interest by possible users).

I believe Force11 should be seen as the forum where discussions on business models would happen. I am not sure how; the yearly conference is one place, but we should probably do more (can have online discussion, webinars, better presence at major events; just throwing things up in the air here). This is essential to achieve any change in my view.

See my comments above...

I think our contribution here was noticeable, although the real merit goes to crossref and similar organization. We should be instrumental, though, in getting the word out. I still meet many people in the scholarly (or related) community who do not appreciate the value of these identifiers (let alone identifiers like ORCID or similar).

Research objects seem to be a very forward looking concept. However, my feeling is that it does not have a real "home" to develop it further, to expose it to the scholarly community, academic institutions, funders, etc. There is a W3C Community Group that is fairly silent. I think that Force11 may have to do some concerted effort to do something like that. ( I say "something" because RO-s may evolve significantly, changing its nature, and we have to embrace that if it happens.)

different interpretations? What does that mean? Isn't that a major problem for interoperability?

At least on my machine, I have to run the

source .../virtualenvwrapper.sh

before any such run. It is not a fixed script somewhere