the Body may also be embedded within the Annotation
What for?
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"?