In-progress draft of Resource metadata (FOR COLLABORATIVE EDITING)

[justinwb]

Per the discussion in the most recent meeting of the data interoperability panel, I'm submitting this incomplete and very much still in-process draft of resource meta-data so that panel members can provide some feedback and deliberate on the content.

Please do not mistake this pull request as a representation that this content in its current form is considered ready to submit to the specification. The purpose of the pull is to give us an easy place on github to collaborate and help get it there.

[kjetilk]

I've realized that I don't understand how it currently works, and I still miss some information to understand it.

The main thing I fail to understand relates to the question: "what is a resource in its own right?"

I've observed that if you add triples to a container, those triples will be added to .meta. In that case, .meta is not a resource in its own right, I suppose. You wouldn't interact with it, you'd interact with the container.

Then, I suppose that if you have an image, and you wish to add metadata to the image, you would do that to a separate resource, and you would get metadata by dereferencing a separate resource. So, in that case, the metadata resource is a resource in its own right. Concievably, you could discriminate between the representations by media type though.

It would be nice to have clarification around that.

[kjetilk]

BTW, I believe we should get to a position where we can check of @dmitrizagidulin 's boxes in solid/specification#63 too

[elf-pavlik]

I have created dedicated issue for media resources and multiple encodings of same creative work #33 . Here I would like to clarify if we talk about description of each of those encodings or description of the creative work which can have numerous encodings?

[elf-pavlik]

If we just talk about different representation of the same resource, I think we could simply use rel="alternate" together with type="image/jpeg" http://microformats.org/wiki/rel-alternate#With_type

When used in combination with the type attribute (with a value other than that of the document itself; e.g. other than "text/html"), rel="alternate" means a link to a representation of the contents of the current document in a different format, as designated by the type attribute.

If we talk about relating a creative work to multiple different encodings, each of which can have their own encoding specific rdf representation, i think should discuss it in #33

[justinwb]

Would you say that the proposed approach we describe here gives us the basic capabilities needed to make these associations (for example in the content of the resource description metadata resource)?

[justinwb]

I've realized that I don't understand how it currently works, and I still miss some information to understand it.

The main thing I fail to understand relates to the question: "what is a resource in its own right?"

@kjetilk Take a look at latest changes, which stipulate that metadata resources on the same server follow the LDPR interaction model, and then (in implementation patterns) that servers know/maintain which resources are metadata, and can apply special handling to them.

[justinwb]

BTW, I believe we should get to a position where we can check of @dmitrizagidulin 's boxes in solid/specification#63 too

Agree - I've added a temporary section at the bottom where I went through every related issue I could find, and then extracted items / points that need to be addressed. #63 was contributed to most of them.

[elf-pavlik]

solid/specification#58 (comment)

2. If a resource is deleted and its .acl remains, the .acl is undiscoverable and its container undeleteable

Besides discussions like in https://github.com/solid/specification/issues/131 it seems that server have full control over assigning location of acl resource for any protected resource. In that case server can choose very specific location for it eg /.well-known/solid-meta/wac/{uuid} or /.well-known/solid-meta/wac{resource_path} (anything that clients would not try to use to create non meta data resources). This way acl resources could get treated as regular LDP Resources including containment etc. Personally I find adding notion of 'hidden / unlisted' resources carrying some design smell. For example if server just appends .acl it has to prevent clients from creating any non acl resource with path ending in .acl, this would especially affect handing creation with PUT and may require special error messages like 'path reserved for server created metadata'.

[kjetilk]

I've realized that I don't understand how it currently works, and I still miss some information to understand it.
The main thing I fail to understand relates to the question: "what is a resource in its own right?"

@kjetilk Take a look at latest changes, which stipulate that metadata resources on the same server follow the LDPR interaction model, and then (in implementation patterns) that servers know/maintain which resources are metadata, and can apply special handling to them.

It doesn't quite address my problem, the behaviour I see, in the case of directories, for example, is that /.meta contains the triples of the container. There is no discovery involved, I would guess, since the /.meta is manipulated through the container, not its own URL.

I'm also in similar kind of doubt about other media types, you could in principle manipulate the XMP or IPTC metadata in images through manipulations on the RDF. Currently, it is rather counter-intuitive to me that it should be done that way, but these are some expectations that should be researched.

Also, note that LDP interaction models doesn't have an important place in Solid. In particular, there is no requirement on the client to supply a Link header to identify the expected interaction model, so the metadata mechanism shouldn't be too tightly coupled to LDP interaction models.

[elf-pavlik]

It doesn't quite address my problem, the behavior I see, in the case of directories, for example, is that /.meta contains the triples of the container. There is no discovery involved, I would guess, since the /.meta is manipulated through the container, not its own URL.

In that case use of /.meta sounds like implementation internal detail. On the other hand, for sake of portability we might want to specify that exported container should include all the statements, no matter how given implementation chooses to persist them in filesystem or elsewhere.

[kjetilk]

In that case use of /.meta sounds like implementation internal detail. On the other hand, for sake of portability we might want to specify that exported container should include all the statements, no matter how given implementation chooses to persist them in filesystem or elsewhere.

Indeed, in that case it is an internal issue, so that's what I need to understand, when is it an internal implementation detail, and when is it a resource in its own right.

[justinwb]

In that case use of /.meta sounds like implementation internal detail. On the other hand, for sake of portability we might want to specify that exported container should include all the statements, no matter how given implementation chooses to persist them in filesystem or elsewhere.

Indeed, in that case it is an internal issue, so that's what I need to understand, when is it an internal implementation detail, and when is it a resource in its own right.

Any reference to ".meta" is an implementation detail to me. Specifically, .meta was a place to stuff metadata for a given resource (in this case a container) on the filesystem in node-solid-server. The goal here is to look a level above that where a given resource (binary, rdf, or container) is able to identify where to look for other types of metadata associated with it. Consequently, I believe that we need to treat all of these as resources in their own right, and leave it up to the servers to know when something is meta (if its on the same server), and add special handling accordingly.

[justinwb]

Another update pushed - I think this is close to a full draft now. Included descriptions for server managed and configuration metadata types. Clarified interaction model points, and cleared open questions. Note that two issues were created from the open questions: #36, #37

[csarven]

I propose to include the following criteria under the Metadata Discovery section on how clients can discover resources and metadata resources (adapted from https://www.w3.org/TR/ldn/#discovery ):
"
Clients do the following to discover resources and their metadata:

• make an HTTP HEAD or GET request on the target URL, and use the Link header with a rel value of a metadata type.
• make an HTTP GET request on the target URL to retrieve an RDF representation [RDF 1.1], whose encoded RDF graph contains a relation of metadata type.

These may be carried out in either order, but if the first fails to result in discovering the metadata resource or the resource the second MUST be tried.
"

[csarven]

If the role of ldp:constrainedBy ( solid/specification#44 ) is in scope, it should be stated.

[justinwb]

These may be carried out in either order, but if the first fails to result in discovering the metadata resource or the resource the second MUST be tried.

@csarven MUST feels a bit strong here. Is SHOULD good enough?

[justinwb]

If the role of ldp:constrainedBy ( solid/specification#44 ) is in scope, it should be stated.

@csarven I could see a role for ldp:constrainedBy in response when something fails Access Control or Shape Validation (or something similar in the future).

[csarven]

These may be carried out in either order, but if the first fails to result in discovering the metadata resource or the resource the second MUST be tried.

@csarven MUST feels a bit strong here. Is SHOULD good enough?

MUST is required for interop in that it guarantees discovery by trying both possibilities. The key point about the requirement is setting an implementation's capability ie. checking both places one after another for any resource. Whether they want to or not for a particular target resource is at their discretion. For example, the LDN spec notes targets with fragment identifiers and that there is no point in checking the Link header to discover the inbox because the relation can only be found in RDF body. Similarly, for a non-RDF target resource eg. binary image, only the Link header needs to be checked.

[csarven]

If the role of ldp:constrainedBy ( solid/specification#44 ) is in scope, it should be stated.

@csarven I could see a role for ldp:constrainedBy in response when something fails Access Control or Shape Validation (or something similar in the future).

That's essentially what the LDP spec recommends. I was hoping for something more concrete re: https://gitter.im/solid/data-interoperability-panel?at=5e3abdde594a0517c26ac1fb given the alternative take with solid:shape. Basically addressing issue 44 (perhaps specific questions in solid/specification#44 (comment) can shed light?)

[justinwb]

If the role of ldp:constrainedBy ( solid/specification#44 ) is in scope, it should be stated.

@csarven I could see a role for ldp:constrainedBy in response when something fails Access Control or Shape Validation (or something similar in the future).

That's essentially what the LDP spec recommends. I was hoping for something more concrete re: https://gitter.im/solid/data-interoperability-panel?at=5e3abdde594a0517c26ac1fb given the alternative take with solid:shape. Basically addressing issue 44 (perhaps specific questions in solid/specification#44 (comment) can shed light?)

@csarven Added a comment on solid/specification#44. For starters I will update the text to illustrate the use of ldp:constrainedBy in response to a request that violates each type of constraint.

[justinwb]

@csarven Added a comment on solid/specification#44. For starters I will update the text to illustrate the use of ldp:constrainedBy in response to a request that violates each type of constraint.

As I sit down to do this - it occurs to me that explaining how ldp:constrainedBy is incorporated into responses based on a given constraint probably belongs in a separate section. Either it should go in a section specific to error handling, and/or it should go into a section specific to how constraints are defined and/or evaluated. The section for resource metadata focuses on how you associate that there is a constraint associated with a resource, but doesn't go into detail on how that constraint be defined and/or evaluated.

[justinwb]

At this point resolutions have been committed based on feedback, and this text is now being moved into bikeshed format to be submitted as a candidate proposal to the https://github.com/solid/specification. No need to maintain this pull for collaborative editing.