WP affords inclusion of data

[TzviyaSiegman]

2.1.5 Inclusion of Data
Web Publications should be able to include data as resources, just as it does with text, images, etc.
Picking up #52

[HadrienGardeur]

How does this affect affordances at all?

[HadrienGardeur]

IMO, this should be closed as an issue.

We don't prohibit data in our list of resources, and this is definitely not an affordance. We can open a separate issue regarding the infoset (if anything needs to be changed).

[iherman]

I actually do not believe there is anything to be done in the infoset. Currently a WP may refer to any Web resource, wether it is media, data, or whatever. I agree this is ripe for closure...

[BigBlueHat]

Let's not just arbitrarily close it because it's solved. Let's make sure we point out that 2.1.5 Inclusion of Data is afforded via the ability to reference any type of resource (not just HTML) as part of the publication.

Ideally, we map all these use cases (and how they are afforded via a WP) into the specification, and not just close them because we think we've done it...only time will tell. 😄

[iherman]

I agree that such pointer to the UC should (nay, must...) be made, but that is a general action not specific to this issue. This is a systematic work we should do, say, when the affordances are a bit clearer (at the F2F?); keeping the issue just for that purpose is a bit confusing imho.

[iherman]

@BigBlueHat, in view of what I said in #135 (comment), would you agree closing this issue?

Maybe a separate issue should be raised saying that all affordances, when we have a final list, should be linked back to the UCR (or the UCR should be updated).

[jmulliken]

The Affordances TF is working on linking each affordance issue and in turn each affordance in the draft to UCs. I think it's okay to close this issue re data inclusion, but I'll leave it in case anyone has objections. FYI we will discuss it on the Affordance TF follow-up call.

[iherman]

David & Benjamin will make a writeup for this affordance, based on the discussion on 2018-05-31

[BigBlueHat]

I've not been able to sync up with @prototypo about this yet, but here's my take on it--which I'm happy to iterate with David when he's available.

Web Publications affords Inclusion of Data

Short Description

Web Publications afford the inclusion of data by uniquely referencing constituent parts of the publication as data either via the use of data-focused media types (ex: text/csv) and (optionally) through some additional metadata about the specific resource (perhaps via something like the Web Annotation Classes system).

Dependency

• Web Publication resources MUST be able to have their media type (MIME type) declared.
• Web Publication resources MAY have additional resource-specific metadata which states their intended use (i.e. {"@type": "Dataset"})

Use case

• 2.1.5 Inclusion of Data
• 2.2.5 Metadata and Resources

Examples

Partial manifest:

{
  "resources": [
    {"href": "data.csv", "format": "text/csv", "@type": "Dataset"}
  ]
}

Direct resource link from markup:

<a href="data.csv" type="text/csv">Data</a>

Testing

Test that...

• a publication resource is uniquely identifiable as data from the resource list
  • via it's media type (i.e. text/csv)
  • (optionally) via an additional metadata statement about that resource (TBD; possibly {"@type": "Dataset"})
• a publication resource identifies itself as data
  • via it's media type (i.e. it's correctly served as text/csv)
  • (optionally) via some self-delivered metadata (i.e. HTTP header or included metadata encoding specific to the resource's format)

[iherman]

@BigBlueHat at the moment, this is not absolutely in sync with the JSON-LD manifest specification. The formalism would be something like:

"resources": [{
   "@type" : "PublicationLink",
  "fileFormat" : "text/csv",
  "rel" : "something"
]}

apart from a different term for media type the usage of @type would not work that way. Maybe the additionalType of schema.org may work, though; if necessary, that can be used (should be documented, though).

(Note the separate discussion on what type to use there on #232 (comment))

[BigBlueHat]

@iherman thanks for the clarification. I'd prefer alternateType in this case because rel is about the relationship between the referencing document and the referenced document--and not merely a "this is a dataset" declaration. I'll dig into #232, though. Thanks!

[iherman]

My problem using alternateType is that we end up using two different, and orthogonal means of identifying the nature of the resource we are talking about: types and relationship values. We shouldn't; we should, imho, using one mechanism.

• We have used, so far, rel, mainly relying on the fact that the IANA registry provides us with a large palette of values, maintained independently of us. It is not complete (we have already hit the limits), in which case we have to use our own URL-s, but it does cover a lot. Actually, if, possibly, we use schema:LinkRole (see Additional resources #232 (comment)) and schema:linkRelationship we even have a slightly bigger freedom because it allows the usage of our own strings instead of URL-s.
• If we go down the alternateType route, we have to have the same richness of possibilities in terms of a type hierarchy. The Annoation Model's classes are way poorer I am afraid, and we may have to maintain a full hierarchy ourselves, cherry-picking various types wherever we find them.

My feeling is, although I would prefer to use a type hierarchy which is closer to my Semantic Web mind, pragmatism dictates that rel/linkRelationship is better for us...

[TzviyaSiegman]

I agree with @iherman. We also need to consider what is implemented on the Web today.

[wareid]

Affordances addressed in the UCR document, as mentioned in the meeting on Feb 4 2019, I am closing this issue.