Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
@namedgraph_twitter There was a whole PR welcoming feedback like the one you're making now.
Can you link or quote the bit that you don't agree with?
As for "containers", here is the definition that's used in the spec: http://solid.github.io/web-access-control-spec/#container-resource
A container resource is a hierarchical collection of resources that contains other resources, including containers.
As for Solid or LDP thing... I can only assure you that there was no intention to couple any of that with WAC whatsoever. If there is a hint of it, do let me know because I'll consider that as a bug.
Here is the non-normative section on HTTP Interactions: http://solid.github.io/web-access-control-spec/#http-interactions
This specification does not describe the HTTP interaction to read-write resources. It is assumed that servers have a mapping to handle HTTP requests and the required Authorizations to grant operations on resources. Implementations are strongly encouraged to use existing approaches that provide an extension of the rules of Linked Data
Hi @/all - given some movement and activity of late related to client/server notification protocols, the protocol editors have created an issue at solid/process#258 to gauge interest in re-establishing the notifications panel to advance proposals and implementation work:
Please see solid/process#258 and :+1: / :-1: / comment if you’re interested in participating.
@csarven As @jeff-zucker mentioned I've been looking into this type of thing, I'm still trying to learn about RDF overall :).
You say using schema:step with rdf:List. Shouldn't that be avoided? The rdf: vocab doesn't know anything about the schema: vocab, so that would be mixing vocabs and it wouldn't be modeled properly, right? If anyone wants to use schema:step, it should be on a schema:HowTo given that's its domain.
@csarven Ok, same question then, the range of schema:step is schema:CreativeWork, schema:HowToSection, schema:HowToStep, or schema:Text; So wouldn't rdf:List be an invalid value? It would be nice if it weren't though, because we'd be able to have sorted lists :).
If that's valid, is there any way to indicate that the values within the list are one of those? Because the range of rdf:first (a property of rdf:List) is rdf:Resource, so a string for example wouldn't be valid, but a foaf:Person or whatever would, and that's not a valid schema:step.
schema:domainIncludes schema:Recipe ;
schema:rangeIncludes schema:ItemList .
53 replies
Domain and range are not about validation. They are used for inference (adding triples)
@acoburn What do you mean with that? I'll use a different example.
Is this "valid"? or "correct"? or "should I do it"? (I'm not sure about the technical word to describe it).
<#me>
a foaf:Person ;
foaf:knows <#the-lord-of-the-rings> .
<#the-lord-of-the-rings>
a schema:Movie .I would say that's invalid/incorrect/you shouldn't do it, because the range of foaf:knows is foaf:Person, and a schema:Movie is not a foaf:Person.
Person and Movie are disjoint classes
the explanation for this is that RDF is property-centric:
The RDF Schema class and property system is similar to the type systems of object-oriented programming languages such as Java. RDF Schema differs from many such systems in that instead of defining a class in terms of the properties its instances may have, RDF Schema describes properties in terms of the classes of resource to which they apply. This is the role of the domain and range mechanisms described in this specification. For example, we could define the
eg:authorproperty to have a domain ofeg:Documentand a range ofeg:Person, whereas a classical object oriented system might typically define a classeg:Bookwith an attribute calledeg:authorof typeeg:Person. Using the RDF approach, it is easy for others to subsequently define additional properties with a domain ofeg:Documentor a range ofeg:Person. This can be done without the need to re-define the original description of these classes. One benefit of the RDF property-centric approach is that it allows anyone to extend the description of existing resources, one of the architectural principles of the Web [BERNERS-LEE98].
Thanks, I think I understand now :).
So, in the initial example we were talking about schema:step and rdf:List. If we have the following document:
<#it> schema:step ( :foo :bar ) .Which means:
<#it> schema:step _:b0 .
_:b0
a rdf:List ;
rdf:first :foo ;
rdf:rest _:b1 .
_:b1
a rdf:List ;
rdf:first :bar ;
rdf:rest rdf:nil .This is not invalid, but it makes an inference that _:b0 is one of schema:CreativeWork, schema:HowToSection, schema:HowToStep, or schema:Text because that's the range of schema:step, right?. Which is fine because rdf:List is not disjoint with any of those?
