solid / vocab Goto Github PK
View Code? Open in Web Editor NEWSolid Vocabularies
Home Page: https://solid.github.io/vocab/
Solid Vocabularies
Home Page: https://solid.github.io/vocab/
There are currently terms in the solid-app vocab can do not need to be defined there and can be reused from existing vocabs.
Had been on my todo list or quite a while.
The following should be reverted, because
after this has gone back in, we can have a proper conversation about process, and what we'd like to see here.
Given that the acl ontology is now redirecting permanently to the https url, should
that be the new base?
curl -i http://www.w3.org/ns/auth/acl
HTTP/1.1 301 Moved Permanently
Location: https://www.w3.org/ns/auth/acl
There are good reasons to have a security vocabulary served over a secure channel...
Strings for a person's preferred objective, subject, and possessive pronouns.
from gitter chat
elf Pavlik @elf-pavlik Nov 20 15:22
Since solid uses WebID Profiles does anyone see problem with simply registering in type index container for foaf:Person
profile.registerType(solid.vocab.foaf('Person'), 'https://storage.example/civr5dp8p0000n5prdue8qwip/civr5ft5z0000nppr6mrb0i1q/', 'container', true)
elf Pavlik @elf-pavlik Nov 20 15:23
so in this container would keep a copy of WebID profiles of all the people i want to bookmark
so each resource in that container would have<> foaf:primaryTopic {webid}
just as WebID Profile it keeps copy of
elf Pavlik @elf-pavlik Nov 20 15:30
profile.registerType(solid.vocab.foaf('PersonalProfileDocument'), ...)
but that dosn't work if i want register containers to collect copies of profiles for groups, projects, organizations, places, events, books, movies ... anything
elf Pavlik @elf-pavlik Nov 20 15:45
registering types of things that documents describe seems more practical then trying to register types of documents
elf Pavlik @elf-pavlik Nov 20 15:50
vcard:VCard
doesn't seem to distinguish the thing from the document asfoaf:Person
andfoaf:PersonalProfileDocument
do
The vCard class is equivalent to the new Kind class, which is the parent for the four explicit types of vCards (Individual, Organization, Location, Group)
above suggests thatvcard:Individual
matchesfoaf:PersonalProfileDocument
and notfoaf:Person
elf Pavlik @elf-pavlik Nov 20 15:57
and if social graph should rely on vcard then WebID and Solid WebID Profiles Spec should also use vcard not foaf
elf Pavlik @elf-pavlik Nov 20 16:16
http://vowl.visualdataweb.org/webvowl/index.html#iri=http://www.w3.org/2006/vcard/ns
:VCard a owl:Class ;
owl:equivalentClass :Kind .
:Individual a owl:Class ;
rdfs:subClassOf :Kind ;
I wonder what @deiu tied to do with https://github.com/linkeddata/contacts/blob/ac9f0888fea289b5645033f1533677d78a7fe932/app/app.js#L333
g.add($rdf.sym(''), RDF('type'), VCARD('VCard'));
g.add($rdf.sym(''), VCARD('hasIndividual'), $rdf.sym('#card')); // hasIndividual doesn't exist!
g.add($rdf.sym('#card'), RDF('type'), VCARD('Individual'));
elf Pavlik @elf-pavlik Nov 20 16:25
https://www.w3.org/TR/2004/REC-owl-guide-20040210/#equivalentClass1The property owl:equivalentClass is used to indicate that two classes have precisely the same instances.
given turtle excerpt from vcard ontology describing relationship between
vcard:VCard
,vcard:Kind
andvcard:Individual
I underatand that each instance with typevcard:Individual
has also typevcard:VCard
what then solid-contacts means bysolid-hacks:hasIndividual
<> a vcard:VCard ;
solid-hacks:hasIndividual <#card> .
<#card> a vcard:Individual .
elf Pavlik @elf-pavlik Nov 20 16:32
https://www.w3.org/TR/owl2-primer/#Class_HierarchiesStating that Person and Human are equivalent amounts exactly to the same as stating that both Person is a subclass of Human and Human is a subclass of Person.
Support additional languages in pim/space, solid/terms...
Where can I find documentation on intended use of ws:Storage and ws:Workspace? As I understand now:
Personal/Controlled/Public Storage & Private/Shared/Public Workspace
A profile may have multiple pimspace:storage
s, and it is not clear for applications which to use - it can be arbitrary in every use. So it'd be useful to be able to declare the master or preferred storage space e.g., with property pimspace:masterStorage
or pimspace:preferredStorage
. This is along the lines of pimspace:masterWorkspace
.
All human-facing text in acl.n3 needs a review by an English speaker with native-level fluency. There are a number of minor idiomatic and/or grammatical errors (things like including a "to" in a verb conjugation where it doesn't belong) in the current texts. (I noticed them in adjacent text when skimming a recent PR after it was merged, which I hadn't read over before the merge or I'd have suggested the fixes there.)
I think I found a typo in the ACL ontology, as retrieved from http://www.w3.org/ns/auth/acl.
On line 16: acl:label "access"@en .
On line 26 and later: :label "append"@en;
The ACL namespace doesn't define 'label', but the rdf-schema, with prefix :
, does.
I'm not sure if this is the right place to enter this issue, but I hope someone here knows what is :)
Currently we don't know a storage's workspaces. What we know (or do e.g., databox.me and some of the practices in our own profiles / preferencesFile) is that a user has workspaces, which can be seen as a single grouping of workspaces, and the storage in which they may be in is inferred through agent's ws:storage
property.
I think this can be improved by using the property ws:workspace
on instances of ws:Storage
(or its subclasses), instead of using it on foaf:Agent
. It will make it possible to declare different workspaces to different storages, especially when users may have multiple storages.
This is used as a way in the Solid Authentication for a user to say that a given web app (origin) is trusted and should not be blocked by cross-site security.
re: http://www.w3.org/ns/pim/space
ws:storage a rdf:Property;
:comment "The storage in which this workspace is";
:label "storage";
:range ws:Storage;
owl:inverse [
:label "workspace included" ] .
To me that seems like the rdfs:domain
of ws:storage
should be ws:Workspace
, and used like this, e.g:
<http://example.org/workspace/>
a ws:Workspace ;
ws:storage <http://example.org/> .
<http://example.org/> a ws:Storage .
However, all the uses that I've come across attach it to foaf:Agent
, e.g:
<http://csarven.ca/#i>
a foaf:Agent ;
ws:storage <http://example.org/workspace/> .
<http://example.org/workspace/>
a ws:Workspace .
@timbl @deiu The wording in the rdfs:comment
is throwing me off, would you mind clarifying. I don't see how it should be an agent's property. There is no rdfs:domain defined for the property so, in practice anything can go in there but, what was the original intention?
This is splitting off a thread from another issue: solid/solid#35 (comment)
edit to clarify: we're interested in this issue as it applies to solid, not in general.
The meaning of an RDF graph depends on the meaning of the predicate URIs (aka property ids) used in that graph. If I say {<sandro> <http://example.org/likes> <salmon>}
, and we assume for now the terms <sandro>
and <salmon>
have their conventional meanings, that statement might mean I like salmon, or I hate salmon, or I am a salmon, or I own some salmon, or ... practically anything. It totally depends on what the predicate <http://example.org/likes>
is accepted to mean. That triple might mean I promise to pay $1000 to each person who walks up to me and says "spaghetti". If we all agreed that's what it meant, that would be okay. (Similar issues arise around the terms <sandro>
and <salmon>
but they're no harder to solve, so let's worry about them later.)
The problem is, how do we all come to agreement about what a predicate URI means? And what happens if that meaning changes over time?
If I was mistaken about the meaning of that term when I made that statement, I've ended up accidentally providing false information. If the meaning changes after I make the statement, and it's not clear the meaning has changed, I've been turned into a liar.
In general, at this point, the RDF community shrugs and doesn't worry too much about this. I suggest this is one of the reasons people who need their computers to do the right thing shrug and walk away from RDF. This github issue is a place for folks to talk about this a little, if they want.
There is vast history around this. I think it was most actively discussed in 2002-2003 as the RDF Core WG tried to decide what the new RDF specifications should say, under the heading "Social Meaning" (as opposed to "formal meaning", as in the formal model theory for RDF). Eventually they decided consensus was impossible and chose to remain silent.
Two bits of historical reading:
I'm sure there's lots more.
I don't know of any credible solution yet. It's become clear to me that dereference is of little use, because it doesn't guarantee stability. And a standards process is also of little use because it's just too slow and expensive. The best we can do today is a very slow and expensive combination of things: make a standard, have an active community that agrees about the meaning, and also make dereference work. And even that's not good enough for many applications areas, I suspect.
I think the solution is going to be something where the text of the spec is provably frozen, and there's good mapping between versions, so meanings can nicely evolve, free from any confusion about which meaning was intended when a given document was written, but also usable when the meaning hasn't changed too much for a particular application. Two of my sketches in this direction are http://decentralyze.com/2014/06/30/growjson/ and http://www.w3.org/ns/mics .
There is a typo in the following vocab:
http://www.w3.org/2005/01/wf/flow#
As we dont have a repository for this vocab it was suggested to raise it here.
Poperty should be renamed to Property
It would be great if someone could help
The solid protocol refers to this type but it is not defined in the vocab. See https://solidproject.org/ED/protocol#server-patch-n3-type
The type registry spec mentions the following new terms.
Add them to the solid-terms
vocabulary:
publicTypeIndex
privateTypeIndex
TypeIndex
ListedDocument
UnlistedDocument
TypeRegistration
instance
instanceContainer
forClass
I would like to include in content, which I publish on The Web, attribute apps which I used for generating given content. So far as:generator seems to me like an appropriate property.
@melvincarvalho I would also use that later myself for statistics on how much i use which app and using it as factor in prioritizing how I express my gratitude to contributors of given app 🎁
It seems when building something like a POD manager, quick access and searchability of all Things in the POD and all Apps registered to the POD is a necessary ingredient. Right now, there's no dedicated registries for these items. TypeIndex might be usable, but it seems like it would be good to split these out into separate registries.
They would need to also include private and public indexes as well.
Decide on whether to have a "core" vocabulary and the rest e.g., apps, server, ..?
Decide on whether to use a single or multiple namespace (depends on previous point).
app ConfigurationFile can have a property to indicate the license that the user when creating content/media with that application.
The user can also have have a default license of their choice which they'd like use when creating/remixing content.
gh-pages
, so they can be easily accessible from github.ioI'm going to update a Solid application and I want it to upgrade the data on PODs that interacted with older versions of my app. In order to know if this is necessary, and in case it is what needs to be modified, I need to know which was the last version that interacted with the POD. An analogous concept with databases would be migrations. Because the POD may still be accessed with old versions of the app, or even other apps who understand the previous schema, all changes will be backwards compatible.
In order to achieve this, and maybe other features, it is necessary to store which version of the app interacted with the POD. I guess in a more complex scenario this could be granular per-container or something, but for now that's a use-case I'm not contemplating.
What I will be doing for now is use the http://vocab.org/open/ ontology and write the following information to /settings/prefs.ttl
(read from pim:preferencesFile
):
<https://userdomain.com/profile/card#me> <http://open.vocab.org/terms/uses> <https://github.com/user/app/releases/tag/v0.1.1> .
With this, I'll be able to know the latest version of the app and upgrade the data accordingly. But I think we could have something more specific to Solid, because I'm not sure using the settings file is the best idea.
This issue was originally raised at https://gitter.im/solid/node-solid-server?at=59f0b46501110b7231fd132e with some interest in its use:
In order for applications to respect a user's privacy (to some extent [*]) an agent's profile description can signal their preferred proxy endpoint. Applications upon discovering this property (eg solid:proxyUrl
or solid:preferredProxy
?) can use it where applicable. When this piece of information in not available, applications would typically use their built-in proxy endpoint as default. Hence, once the agent's preferred proxy endpoint is known, cool applications can override the default (eg linkeddata/dokieli#230 )
solid:preferredProxy
a rdf:Property ;
rdfs:label "preferred proxy" ;
rdfs:comment """An agent's preferred proxy endpoint for consuming applications to use. The value of the property is intended to be used as the base URL for the request eg. the preferred proxy as literal: `https://example.org/proxy?uri=` would be used to request `https://example.net/profile/card#me` as `https://example.org/proxy?uri=https://example.net/profile/card%23me`"""@en ;
rdfs:domain foaf:Agent ;
rdfs:range rdfs:Literal
.
domain and range could be omitted in the vocabulary definition document. Range is a literal because we want the application to use that as the base URL for the intended request.
Example profile statement:
<http://csarven.ca/#i>
solid:preferredProxy "https://example.org/proxy?uri=" .
I could not find an existing vocabulary that would indicate this, so I'm raising it here.
[*] Obviously applications do not have to care about this nor should agents rely on the application to use their preferred proxy endpoint. The bottom line is of course the level of trust an agent puts on the application that they use - which could very well mean that the application will use their built-in proxy endpoint for certain operations.
Proposal to drop solid terms' timeline
property and Timeline
class.
Intended semantics and usage overlaps with https://www.w3.org/TR/activitypub/'s Outbox: https://www.w3.org/TR/activitypub/#outbox - which is basically a container/collection of activities. There is also a growing list of applications/servers that implement https://activitypub.rocks/implementation-report/ , hence more likely to work interop with.
In contrast tot as:outbox, solid:timeline for instance is underspecified.
If there is nothing mission critical or great adoption, I suggest favouring/encouraging the use of as:outbox
instead of solid:timeline
.
If you are using solid term's timeline in an application, please indicate if it is actively used or still in working condition along with the URL to the application. If you are against the proposal to remove, please indicate if/why solid:timeline
is preferable to you over as:outbox
.
(Putting ws:masterWorkspace
aside) ws:workspace
only leads to Workspaces, which would then require a second round of requests for all of the workspaces to discover the application workspace.
I think we need a specific property to help discover the application workspace (i.e., which is an instance of a solid-app:PreferencesWorkspace
faster. It is sufficiently high profile that it deserves its own dedicated property.
ws:applicationWorkspace a rdf:Property ;
:label "application workspace";
:range ws:Workspace;
#or :range solid-app:PreferencesWorkspace;
Example usage:
<http://example.org/> ws:applicationWorkspace <../Applications/> .
<../Applications/>
a <http://www.w3.org/ns/solid/app#PreferencesWorkspace> ,
<http://www.w3.org/ns/pim/space#PreferencesWorkspace> ,
<http://www.w3.org/ns/pim/space#Workspace> ;
<http://purl.org/dc/terms/title> "Applications preferences workspace" .
It seems that webmention link relaion will have canonical URI hosted by IANA
Maybe solid can use it instead of defining new term inbox ?
ontology info that can be used by an installer on a solid server, to automate the installation (and presentation) of a new app.
Needs to be updated:
http://www.w3.org/ns/spec
Needs to be published:
https://www.w3.org/ns/solid/notifications-context/v1
http://www.w3.org/ns/solid/notifications
@pchampin , will also assign the issue to you once you accept the invitation to be a collaborator in this repo.
Linked Data Fragments has VOID as informative reference
Few observations and questions:
I will try to add more comments here in next days!
As an extension of #29 and an solution available for nodeSolidServer/node-solid-server#918, we might need a property that denotes the total size of all files in a given POD. Do we want to introduce this property, and what should it be named?
Building on #35 I propose the property solid:totalFilesSize
.
An example (that could be used in serverSide.ttl):
</> solid:totalFilesSize "13000"^unit:Byte
As per the Solid authentication panel's current proposal, a client's WebID MUST include a single solid:oidcRegistration property.
See: https://solid.github.io/authentication-panel/solid-oidc/#clientids-webid
We possibly could describe it as follow:
solid:oidcRegistration
a rdf:Property ;
rdfs:comment "A JSON serialization of an OIDC client registration, per the definition of client registration metadata from [RFC7591] section 2."@en ;
rdfs:isDefinedBy <http://www.w3.org/ns/solid/terms> ;
rdfs:label "oidc registration"@en .
@acoburn @csarven does this addition and the proposed comment make sense?
currently: http://www.w3.org/ns/solid/terms#
should become: https://www.w3.org/ns/solid/terms#
I started to make a list of ontologies in my tools spreadsheet then came across prefix.cc and wondered about a vocab fetcher, that might go find a suitable term, then help add it via an IDE like sublime or atom, et.al.
One of the issues that seem to exist is a difficulty for people to find existing ontology terms, etc.
The idea here - is to help solve that problem.
It seems that currently solid team promotes practice of dropping additional terms to namespaces under control of someone else. I think that creating dedicated namespace for such terms would provide a cleaner way of doing it.
http://www.w3.org/2006/vcard/ns does not include AddressBook
or hasIndividual
(as used in solid-contacts)
Such terms should have IRIs and definitions in namespace controlled by solid team, if they get adopted by vocab which they patch, combination of owl:equivalentProperty
, owl:equivalentClass
and schema:supersededBy
can help with deprecating term from solid monkey patches.
Hi. Currently the vocabulary does not provide sufficient concepts to represent information related to Pod functionalities. For example, Who developed/provided the App? Who is the Infrastructure provider for Solid? These terms should be provided through the solid vocabs to enable representing use-cases with correct granularity. This vocabulary should also establish the terms for entities that may take different roles in relation to Pods - e.g. who provided the server, who provided the software, etc. Such clarity in terms regarding entities, roles, and functionalities will help transparency in the Pod provisioning and use, maintaining records, and most importantly - legal tasks related to ensuring appropriate responsibilities and agreements are established.
For example, the following are based on existing standard for cloud terminology ISO/IEC 22123-1:2021 Information technology — Cloud computing — Part 1: Vocabulary where Solid is interpreted as a Data Storage technology (Solid
and Pod
are prefixed for informative purposes):
Might be a good idea to have the resources declare their preferred proxy URL. This is so that, proxy URLs can be discovered without hardcoding or maintaining the URLs in the application. That is, the application only needs to find the value of the property, and then use the prefix URL.
Example part of the response:
<http://example.org/> :proxyURLPrefix "http://example.org/,proxy?uri="
and/or:
Example part of the HTTP Header:
ProxyURLPrefix: http://example.org/,proxy?uri=
It is okay to try and use ,proxy?uri=
in applications, but I think that expectation is not necessarily always going to work out in the wild. Servers are going to use whatever pattern they can and want. And, it is likely that they'll re-use an existing one instead of changing its path to a new one so that it is compatible with Solid - which is costly.
A group of participants in the data interoperability panel have proposed the use of Common Core Ontologies by the Solid Ecosystem.
They have shared an example use case in the form of a User Profile, and described its use of CCO as follows:
As an extension of CCO, the User Profile also inherits and re-uses Basic Formal Ontology (BFO) and OBO Relation Ontology. Use of the methodology and standards derived from CCO, BFO, and RO, provides an integration layer for an individual’s profile data that maintains a transparent and unified semantics across domains and applications.
Also related to the above were issues and pulls in the Data Interoperability Panel - solid/data-interoperability-panel#24, solid/data-interoperability-panel#14.
On October 21st, 2019 - Jacob McConomy, Jim Schoening, and Mark Jensen gave a detailed presentation on CCO / BFO. Minutes from that presentation where recorded, and Slides were made available.
Creating this issue for others in the community to consider the use of CCO/BFO/OBO within the Solid Ecosystem.
cc: @mark-jensen, @JKReynolds
For the issue in nodeSolidServer/node-solid-server#841 , which is urgent, we are discussing to add some RDF so that apps can use the data.
I would prefer to use a datatype, so something like this:
<#me> solid:nvmQuota "25"^^ex:megabyte .
but I have also considered the option of e.g.
<#me> solid:nvmQuota [
a solid:MaxQuota ;
posix:size "25000000" .
].
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.