Default subdomain handling (in rdf)

[joshuef]

It seems the simplest solution is to have the triple for the main graph: <safe://publicname> safevocab:defaultServiceInfo<safe://publicname#default> which eventually could be even replaced by just a triple like `safe://publicname safevocab:defaultServiceInfo "safe://"

Such that safe://whatever may point to a default services description reliably, but equally, another subdomain could point there too: safe://random.whatever

[joshuef]

Hmmm. How far do we want to go with this?

I know we've spoken about not using LDP containers here...

https://schema.org/ItemList

Is perhaps a simple clean candidate and has a position property for the Items in the list which could be used for determining order of access (when non explicit is provided) (if one wants fallbacks).

eg taken from the site. If these were SubPublicNames (how's that for a name of a thing?... subdomains is confusing if we call the main string a publicName), beatles.<whatever> would be resolved first. Followed by elvis, if the first was not available (for example).

{
  "@context": "http://schema.org",
  "@type": "ItemList",
  "@url": "http://en.wikipedia.org/wiki/Billboard_200",
  "name": "Top music artists",
  "description": "The artists with the most cumulative weeks at number one according to Billboard 200",
  "itemListElement": [
    {
      "@type": "ListItem",
      "position": 1,
      "item": {
        "@type": "MusicGroup",
        "name": "Beatles",
        "uri:" "<cas URI>"
      }
    },
    {
      "@type": "ListItem",
      "position": 2,
      "item": {
        "@type": "MusicGroup",
        "name": "Elvis Presley"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Michael Jackson"
      }
    },
    {
      "@type": "ListItem",
      "position": 3,
      "item": {
        "@type": "MusicGroup",
        "name": "Garth Brooks"
      }
    }
  ]
}

we of course don't need to abandon the LDP setup, though I feel something akin to this may be cleaner...

thoughts, @bochaco @hunterlester ?

---

and natch... there may be a cost to changing it. namely compatibility.... So the other option is to use a custom safe vocab field and have default entry which maps to one of the other graphs and can be set by an API...

[bochaco]

@joshuef it sounds simpler to me than LDP Containers, or maybe more intuitive and not necessarily simpler, what I don't like about the LDP Containers spec is the way to describe the relationships with http://www.w3.org/ns/ldp#hasMemberRelation, it's either too complex to describe different relationship types for each item/subgraph, or not even possible with LDPCs?

As per the https://schema.org/ItemList, I wouldn't be sure if we should use the position in our implementation (not for the DNS at least) as that makes the impl too complex, I'd love to have a default item but not really a precedence list of items to choose from (ofc we can us the position with value 1 as the default and ignore any other != 1 values, that should be a way of implementing the default).

One thing though, it would be much better if we don't need to nest the item's link into the ListItem, do you know if it would be valid to construct something like:

  "itemListElement": [
    {
      "@type": "MusicGroup",
      "position": 1,
      "name": "Beatles",
      "uri:" "<cas URI>"
    },
    ...

I'm wondering if there are other specs for lists, were you able to search for others out there? I only did a quick search and found there is a collection in the RDF spec itself but it's like a linked list which I don't really like (at least not for this purpose): https://www.w3.org/TR/rdf11-mt/#rdf-collections

[bochaco]

@joshuef , shall we just close this and leave it to be solved by the implementation of the Public Names RFC ? or do we want to keep this and eventually implement it as an experimental feature with current APIs in safe-app-nodejs?