The identity of the SpecificResource is separate from the descriptions of the constraints.
Why?
SpecificResource can be uniquely identified by a composite identity of URI of Resource + constrains.
That would allow to escape the need to have another extraneous unique id registered.
Also that would allow different parties to deterministically uniquely identify the same SpecificResource without any communication.
fragments for HTML cannot be used to describe an arbitrary range of text
How to do so?
"type": "Video"
Even if no "format" is specified in an Annotation it may be specified in an External Web Resource.
"type": "Video"
Some clients may support one specific type and not support another specific type.
By supplying generic type with no specific type we may encounter a case when a client may not be able to tell based on a generic type whether it can handle data or not.
E.g., a client may support video/mp4 and not support video/ogg, leaving it unable to predict whether it can handle data typed as "video".
It seems to me that a scenario when a client is not able to handle all specific types of a generic type is rather common.
3.2.2 Classes
Can a specific type be expressed via Classes?
it is also useful for a client to know that a resource with the format text/csv should not simply be rendered as plain text
It should be up to a client to decide how handle data.
It is useful for clients to know the general type of a Web Resource in advance.
Ain't a general type can be derived out of a specific one?
E.g., it is possible to derive a generic type of a specific mime type, because mime types have structure of type/subtype.
E.g., video/mp4 -> video
if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded
Annotation refer an exact value of a resource.
Annotator most likely does not expect this value to change.
However, resources cannot be enforced to be immutable.
Allowing an annotator to provide such local parameters would allow them to rely on at least their immutability.
if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded
Ain't it up to Annotation to decide how to view a resource?
if information provided by the external resource contradicts the information provided by the annotation about it, then the external resource is authoritative and the information from the annotation should be disregarded
Why so?
textDirection
Ain't this property can be derived out of 'language' property?
processingLanguage
Why Annotation takes on responsibilities of presentation?
It can be presented in a miriad of ways and it's up to the consumer to decide how to view it up to their preferences.
This information may be recorded as part of the Annotation, even if the representation of the resource must be retrieved from the Web.
This seems necessary, because an author of Annotation may be a third-party for Target or Body, having no control over it, and yet may want to specify some data about it.
the Body may also be embedded within the Annotation
It won't be possible to refernce such Body of a published Annotation.
So it won't be possible to annotate such Annotation.
I.e., it is not possible to use such Annotation for reasoning further on.
That may be fine in case no third-party will ever want to annotate it / use as part of their reasoning, but personally I would not be comfortable to count on that.
Based on that reasoning, it seems to me that for the open web it would be more suitable to require of any published Annotation to have a referencable Body.
the Body may also be embedded within the Annotation
What for?
An Annotation is a Web Resource.
Is it a must for an Annotation to be resolvable?
I.e., can it be not a Web Resource, but a Resource?
Class Resources may be divided, conceptually, into groups called "classes"; members of a class are known as Instances of the class. Resources are associated with a particular class through typing. Classes are identified by IRIs, i.e., they are also Web Resources themselves. Type A special Relationship that associates an Instance of a class to the Class it belongs to. Instance An element of a group of Resources represented by a particular Class.
What is it for?
representation of the Annotation
What parts does representation of Annotation have?
are not to be considered authoritative information
Why so?
collections
What is a "collection"?
The Body resource may be a choice between multiple resources.
Why?
The Target or Body resource may be included in the Annotation to play a specific role.
Why?
The Target or Body resource may be included in the Annotation to play a specific role.
What are such roles?
The Target or Body resource may be a specific state of the resource.
Target may refer to an html Resource.
The Target or Body resource may be a specific state of the resource.
What 'states' are possible?
The Target or Body resource may be styled in a specific way.
Why to style?
rooted
How so?
associations between resources
How to express what annotation refers to?
structured model and format
What's the difference between "structured model" and "format"?
it’s really annoying
I see how comments can be annoying to one.
They may annoy if they are not useful.
And their usefulness depends on use-case (a shocker, I know).
Comments can lead you astray, because they get out of date. The code is the only source of truth.
This is a sign that reasoning is not being captured thoroughly.
These shouldn’t be comments! They should be in commit messages, or the wiki, or the issue tracker, etc
Why should reasoning be spreaded across these places?
Anything created in a project is an artifact of human reasoning, be it a mindset expressed in a text chunk, organization expressed in issues, sprints, etc., or a code block.
All of that is humans' reasoning, some informal - expressed in a natural language; some formal - tickets, mock-ups, code. But it's reasoning nonetheless and it can be expressed in one reasoning graph, from a non-formal idea in a natural language down to a formal implementation in code. If the semantics are captured as data (of a ticket, of a meeting event, etc.), then tools of one's choice can be used by him to work on that data.
RDF is an abstract knowledge representation model that does not differentiate data from metadata.
It seems to me it does.
RDF allows to express nodes and edges that reference nodes. Edges are metadata.
My reasoning is:
However, what RDF does not allow is for an edge to reference another edge.
I.e., nodes are referencable, edges are not.
I.e., RDF does not allow metadata about metadata.
RDF* allows exactly that, unlocking meta-level depth.
Nested Embedded Triples
Opens up a meta-level play.
What RDF* Improves
In RDF there are nodes and edges.
RDF* allows to treat edges as nodes.
:hasSpouse is a symmetric relation so that it can be inferred in the opposite direction
:hasSpouse is a 2-ary relation.
the metadata in the opposite direction is not asserted automatically, so it needs to be added
This is a denormalization.
<<:man :hasSpouse :woman>>
There may be more than one :man :hasSpouse :woman, how to specify the exact one? I.e., statement may not be unique.
What RDF* Improves
A feature of RDF* is that it allows to reference relationships without the need to reify them.
That means no change to data-model is required to be introduced when one wants to reference to a statement.
<< <<:man :hasSpouse :woman>> :startDate "2020-02-11"^^xsd:date >>
Neat.
According to the formal semantics of RDF*, each embedded triple also asserts the referenced statement and its retraction – deletes it. Unfortunately, this requirement breaks the compatibility with the standard reification and causes a non-transparent behavior when dealing with triples stored in multiple named graphs. GraphDB implements the embedded triples by introducing a new additional RDF type next to IRI, blank node, and literal.
So the same syntax (<< >>) is overloaded with a different behaviour in GraphDB?
GraphDB implements the embedded triples by introducing a new additional RDF type next to IRI, blank node, and literal.
Where the formal definition of this type can be found?
According to the formal semantics of RDF*, each embedded triple also asserts the referenced statement and its retraction – deletes it.
Where does it state so?
RDF reification as demonstrated in the example has two major shortcomings
Another shortcoming is that a reified statement is not reified by itself.
Idea of page previews looks interesting.
Scalability: In a many-to-many system, scale is essentially unlimited. Hardware (nodes) can be added at ease in any home or office by anyone, which is not the case with the current data center model.
Yet datacenters have more resource budget before they run out and they provide scale seamlessly.
standard
Some standards seems to be possible to quantify.
E.g., health 86/100
to be maintained over time
How to?
with a standard
What is a "standard"?
it is possible so make following a link fire up a special application
How could it be implemented?
One must also be able to annotate links
Are there any developments on this?
a user de-fined extension namespaces
What is that?
Each SPARQL implementation has its own protocol torealize the binding between extension namespaces and function definitions
I don't get. An example?
limits the interoperability of the query
How so?
query and search
What's the difference between "query" and "search"?
Given the restrictions of the sandboxed iframe, it is not able to make calls outside of its own frame, nor is it able to read or modify anything about the parent page.
Very nice.
they can perform I/O using XMLHttpRequest (although the responseXML and channel attributes are always null) or fetch (with no such restrictions).
It is an isolated environment that is insulated from the window object, the document object, direct internet access
Is it so?
more difficult to maintain
How so?
make our components larger
Overhead of FRP engines baked into WCs may indeed add up to a substantial size by Web standards.
convolute the code
How so?
Notes
I'm curious to see how an example case of 30 ReactJS components with different ReactJS versions are going to look like. Having dependency on a different version of a library is the most likely scenario in practice. How will dependencies be managed in this case?
All components will share the library code
How does it work?
Automatic linking of other resources and discussions
What problem is it meant to solve?
Portability across hosting services
What is meant to be hosted?
Rich connections to other online resources
How is it different from https://hyp.is/r_XCOidrEeytkFOq1NeVnw/www.force11.org/group/annotating-all-knowledge-working-group/attributes-interoperable-annotation ?
Discovery and linking of annotations across different content instances (html vs. pdf)
Rich
What is meant by "rich"?
Many different clients that support basic functionality
Are there any implementations?
Tags that help filter, sort, identify annotations by date, relevance, topic…factual annotations vs. comments (pragmatic vs. true semantic interoperability)
Perhaps RDF is a good fit for it.
People identifiers within groups and globally (SSO including with ORCID), w/ Twitter, other SM groups
Can this problem of identifying people be solved by WebID?
repositories
What is it?
versions of content
What is meant by it?
Selection
What is it?
ability to evolve permissions on selected annotations
How to control who's allowed to evolve?
branded
What is it?
authoritative
What is it?
private group
What is it?
but
Why "but"?