Re: Chartering work has started for a Linked Data Signature Working Group @W3C

Dan,


> 
> 
> 
> Let's try - possible text?
> 
> "Linked Data (RDF) is commonly understood to encode descriptions of real world objects and claims about their properties and relationships.
> 
> Determining exactly how this works is explicitly and very much out of scope of the WG. 
> 
> Some RDF descriptions depend on "reference by description" conventions, e.g. saying in markup "the Country whose name is France". Others use URIs directly such as  http://dbpedia.org/resource/France <http://dbpedia.org/resource/France> or https://www.wikidata.org/entity/Q142 <https://www.wikidata.org/entity/Q142>. Some of these identifiers use 'http:' URIs, some use https: URIs, other URI schemas are sometimes encountered.
> Some users of RDF are aware that, or rely upon, the fact that systems can derive additional claims implied by instance data, by using content from schemas and ontologies. Some RDF descriptions are written in self-contained formats (e.g. N-Triples, RDF/XML, Turtle); others are written in formats that depend on out of band material (e.g. JSON-LD contexts); in the latter case, the RDF graph representation of content can vary even when the instance data is untouched. RDF can also be written in forms in which human-facing content and machine-oriented content are interwoven, but not compelled to express the same claim (e.g. RDFa, Microdata). There is also relatively little consensus amongst RDF applications about the conventions best used for choosing named graph URIs associated with each triple in the quads constituting a Dataset.
> 
> These complexities are real, and affect the environment around signed RDF content, but not the immediate priority of this WG. The approach taken by this WG is that its minimalistic deliverables should provide a foundation of technology components and tools which can over time incrementally address more challenging usecases. While WG members are encouraged to consider the broader ecosystem in their designs (e.g. including hooks for future extensions), the chartered work addresses real usecases, even if other more challenging applications will need additional specifications, conventions or best practice guidance.
> 

When you say "possible text": where? Because I am almost sure that the AC would throw it back if this text was part of the charter; we have been asked to create as succinct a charter as possible. 

This is why I came up with the explainer document.  Do you mean to add this text to the explainer? As a replacement of the text already there[1] or as an additional one?

Alternatively (or additionally), can we come up with a 1-2 sentence out-of-scope statement for the charter?


[1] https://w3c.github.io/lds-wg-charter/explainer.html#ld-and-rdf <https://w3c.github.io/lds-wg-charter/explainer.html#ld-and-rdf>

B.t.w., I have added some extra statements in the explainer in the separate PR[2]

[2] https://github.com/w3c/lds-wg-charter/pull/79


> 
> I tried!
> 
> Short version: make sure (1) and (2) can happen with minimal coupling to (3) and (4), and tone done any grandiosity in the language so that "this is a step towards" is the tone, rather than "this will ensure...".

Dan, is this the same situation as in one of your earlier comments? At the moment the only occurence of the word "ensure" is in the liaison statements and in some of the use cases. I try to understand which grandiose statements you are referring to in the charter or the explainer (I do not care, at this point, whether those statements are present in some of the external documents that we refer to).

Thanks

Ivan



> 
> Dan
> 
>  
> -- manu
> 
> -- 
> Manu Sporny (skype: msporny, twitter: manusporny)
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches <https://tinyurl.com/veres-one-launches>


----
Ivan Herman, W3C 
Home: http://www.w3.org/People/Ivan/
mobile: +33 6 52 46 00 43
ORCID ID: https://orcid.org/0000-0003-0782-2704

Received on Wednesday, 12 May 2021 16:45:03 UTC